Customize the v5 Configuration (Developer Preview)

The default Code Analyzer configuration is designed to meet the needs of most users. But you can also customize how Code Analyzer works by creating a YAML configuration file that can:

  • Configure global Code Analyzer properties, such as the location of the log files.
  • Override the properties of existing rules, such as their severity or tags.
  • Adjust engine properties, including adding custom rules.

We recommend that you name the file code-analyzer.yml or code-analyzer.yaml and put it in the root of your workspace. Each code-analyzer command checks the current folder for either of these files, and if found, applies the overrides. You can also use the --config-file flag to specify a different location or name; this flag is available on all commands.

This feature is available as a developer preview. The feature isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. All commands, parameters, and other features are subject to change or deprecation at any time, with or without notice. Don't implement functionality developed with these commands or tools.

The easiest way to get started is to create a code-analyzer.yml file that shows your current configuration. Run this command, which creates the file in the current folder:

The generated file contains lots of comments to help you create your own customizations. But let’s look at a simple example of an uncommented code-analyzer.yml file to see how this custom configuration works.

The log_folder property is global and specifies the folder that contains all the Code Analyzer log files, in this case /Users/john.doe/code-analyzer/logs.

Use the rules section of the config file to override the severity and tags of existing rules. In the earlier example, the eslint:sort-vars rule has a new severity (Info) and new tags (Recommended and Suggestions). The example then shows how to override the tags of the regex: NoTrailingWhiteSpace rule so that it's no longer Recommended by default.

Use the engines section to customize engines. In the example, the eslint engine is provided with an ESLint Configuration file and the regex engine is configured with a new custom rule called NoTodoComments. This new rule scans Apex code files (which always have the extension .cls or .trigger) for the string TODO.

The regular expression that you specify for the regex property must include a global modifier. For example, this regex value is valid: /Todo/gi. But this value isn’t valid: /Todo/i. If you configure a regular expression that doesn’t have the global modifier, and then try to run the rule, the regex engine returns an error.

Let’s look at the configuration file in action! For comparison, first run this command in a folder that doesn’t contain a code-analyzer.yml or code-analyzer.yaml file:

The command returns this information about the eslint:sort-vars rule:

Now imagine running the same command, but the folder now contains the sample code-analyzer.yml file shown earlier. Because the configuration overrides the properties of the eslint:sort-vars rule, the output now looks like this:

As you can see, the severity is now 5 (Info) and it has the Recommended and Suggestion tags.

This example returns Found 0 rules when you run it in a folder that doesn’t contain the sample config file:

But wait, didn’t we add the NoTodoComments rule to the regex engine? We did, but to use it you must specify the config file! This time, rather than run the command from a folder that contains the config file, we use the --config-file to specify its location.

The command now returns this output, which is exactly what is configured in the code-analyzer.yml file:

The examples in this topic are all for code-analyzer rules command, but the same custom behavior applies to code-analyzer run.

Pretty groovy, huh!