Analyze Your Code with Code Analyzer v5 Commands (Developer Preview)

This section describes the out-of-the-box way to view the available rules and then run them against your code base. It assumes the default configuration. See the next section for information on how to customize your configuration by creating a code-analyzer.yml file.

The best way to get started is to run the rules command without any flags to get a concise list of the recommended rules for all available engines:

The command outputs something like this:

The table output includes these columns:

• The name of the rule. The name is unique within the scope of its engine, but not necessarily unique across all engines.
• The engine that the rule is associated with: eslint, retire-js, or regex.
• The severity of the rule. Options are: 1 (Critical), 2 (High), 3 (Moderate), 4 (Low), or 5 (Info).
• The rule’s tags. In the preceding output, all the listed rules have the Recommended tag because that’s what the command returns by default.

Use the --rule-selector flag to be more selective about the list of displayed rules. For example to display a table of all of the rules and not just the recommended ones, run this command:

To display details about all the eslint engine rules, run:

Run this command to view details about the recommended rules for only the eslint engine:

You can use the --rule-selector flag to select specific rules. For example, this command lists the recommended eslint engine rules that also have the tag problem and a high severity level (2):

The default rule selector is Recommended, which selects the rules from all available engines that have Recommended as one of its tags. But if you provide your own rule selector with the --rule-selector flag, explicitly append :Recommended if you want to stay within the recommended rule set. For example --rule-selector eslint is equivalent to --rule-selector eslint:all, which selects all the available ESLint rules. But you typically want to use rule-selector eslint:Recommended to select just the recommended ESLint rules. The order and case of CLI flag values don't matter, so --rule-selector recommended:eslint also works.

You can specify the --rule-selector flag multiple times to include other engines or other specific criteria; the rules are AND’d together. This example lists all the eslint engine rules that have a moderate (3) severity and the recommended retire-js engine rules with any severity:

Remember the new Regex engine? Run this command to view the details of all its built-in rules:

The preceding examples list the rules based on the value you pass to --rule-selector. But you can also specify a workspace to get a more accurate list of rules that actually apply to your code base. A workspace is the set of files you want to include in your code analysis. A workspace is typically a single folder, although you can specify more files and folders if you want. When you specify a workspace, the rules command uses the file extensions in the workspace, such as .js (JavaScript) or .ts (Typescript), to determine the rules to list. For example, if your workspace contains only JavaScript files, the command doesn't list TypeScript rules. Let’s look at a few examples.

This command lists the recommended eslint rules that apply to the current folder (.):

This command lists all the recommended rules across all available engines that apply to all the files in the ./other-source folder and only the Apex class files in ./force-app:

Now that you’ve used the rules command to narrow down the exact list of rules you want to run, use the run command to actually run an analysis of your code using the same rules. Simply specify the same value for the --rule-selector flag.

When you execute the run command without any flags:

You get this default behavior:

• Analyze the files in the current folder, which is the default workspace.
• Use the recommended rules across all available engines in the analysis.
• Display the output in the terminal with the concise table view.
• Automatically apply rule or engine overrides if a code-analyzer.yml or code-analyzer.yaml file exists in the current folder. See Customize the v5 Configuration for more information about this file.

The default behavior is just like running this command, where the code-analyzer.yml file is either empty or contains only default values:

Use the --rule-selector flag to select the set of rules you want to run; this flag works the same as with the rules command. See List the Available Rules for lots of examples of using the --rule-selector flag, which you can also use with the run command. Here are a few examples, such as this one that runs all the eslint engine rules and shows details about the violations:

Run all available rules:

Run all the eslint engine rules that have a moderate (3) severity and the recommended retire-js engine rules with any severity:

Run a single regex engine rule:

If you don’t specify a workspace, the run command analyzes the files in your current folder by default. But you can use the --workspace flag to specify the exact files or folders you want to analyze, and even use globs patterns (wildcards). If you specify the flag more than one time, then your workspace is the sum of the files and folders. In this example, the workspace consists of all files in the folder ./other-source and only the Apex class files (extension .cls) in the folder ./force-app.

By default, the analysis results are displayed to the terminal. Use the --output-file flag to also write the results to a file. The format of the file depends on the file extension that you provide, such as .csv for comma-separated values or .html for HTML. This example outputs to both a CSV and HTML file:

We’ve improved the HTML output, so give it a try! It now looks like this:

You can specify a severity threshold so that the command fails with a non-zero exit code when a violation meets or exceeds the threshold. The example has a threshold of moderate (3):

These examples all use the default configuration. Read the next section to learn how to customize how Code Analyzer works.