The default Code Analyzer configuration meets the needs of most users. However, you can also customize how Code Analyzer works by creating a YAML configuration file that helps you:
If you include the same file in both target and ignores objects then the ignores setting takes precedence and the file isn’t analyzed for violations.
Note
We recommend that you name the file code-analyzer.yml or code-analyzer.yaml and put it in the root of your workspace. The VS Code extension, and each code-analyzer CLI command, checks the current folder for either of these files, and if found, applies the overrides. When using CLI commands, you can also use the --config-file flag to specify a different location or name. This flag is available on all CLI commands.
The easiest way to get started is to create a code-analyzer.yml file that shows your current configuration. Run this CLI command, which creates the file in the current folder.
1sf code-analyzer config --output-file code-analyzer.ymlThe 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.
1log_folder: /Users/john.doe/code-analyzer/logs
2
3ignores:
4 files:
5 "**/utils.js"
6rules:
7 regex:
8 NoTrailingWhitespace:
9 severity: 2
10 disabled: true
11
12rules:
13 eslint:
14 sort-vars:
15 severity: Info
16 tags: ["Recommended", "Suggestion"]
17 regex:
18 NoTrailingWhitespace:
19 tags: ["CodeFormat"]
20
21suppressions:
22 disable_suppressions: false
23 "src/controllers/":
24 - rule_selector: "eslint:complexity,pmd:CyclomaticComplexity"
25 max_suppressed_violations: 50
26 reason: "Technical debt from v1.0 - tracked in JIRA-1234"
27
28engines:
29 eslint:
30 eslint_config_file: .eslintrc.json
31 regex:
32 custom_rules:
33 NoTodoComments:
34 regex: /Todo/gi
35 file_extensions: [".cls", ".trigger"]
36 description: Prevents TODO comments from being in Apex code.
37 violation_message: Found a comment in an Apex file with a TODO statement.
38 severity: Moderate
39 tags: ["Recommended", "CodeFormat"]The log_folder property is top-level and specifies the folder that contains all the Code Analyzer log files, in this case /Users/john.doe/code-analyzer/logs.
Use the ignores section of the code-analyzer.yml file to ignore violations from a specific file or a group of files. To ignore violations from a specific file, provide the relative path of the file. For example, "**/utils.js" ignores violations in utils.js in your project.
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. You can also ignore violations of specific type in all the files in your workspace using the disabled property.
Suppress violations from a specific file or folder by using the suppressions section of the code-analyzer.yml file. See suppression object properties for more information.
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
Tip
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:
1sf code-analyzer rules --rule-selector eslint:sort-varsThe command returns this information about the eslint:sort-vars rule:
1# Name Engine Severity Tag
2 ─ ───────── ────── ──────────── ─────────────────────────────────────
3 1 sort-vars eslint 3 (Moderate) BestPractices, Javascript, TypescriptNow 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:
1# Name Engine Severity Tag
2 ─ ───────── ────── ──────── ───────────────────────
3 1 sort-vars eslint 5 (Info) Recommended, SuggestionAs 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:
1sf code-analyzer rules --rule-selector regex:NoTodoCommentsBut 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.
1sf code-analyzer rules --rule-selector regex:NoTodoComments --config-file ../code-analyzer.ymlThe command now returns this output, which is exactly what is configured in the code-analyzer.yml file:
1# Name Engine Severity Tag
2 ─ ────────────── ────── ──────────── ───────────────────────
3 1 NoTodoComments regex 3 (Moderate) Recommended, CodeFormatThe examples in this topic are all for code-analyzer rules command, but the same custom behavior applies to code-analyzer run.
Pretty groovy, huh!
j