--- schema_version: "1" id: 7794443800743cb4893e1704230f589dc11b5088daf157cd684f2e676de9ce22 title: Customize the Configuration collection: developer version: current locale: en-us portal_url: https://docs.salesforce.com/developer/current/en-us/code-analyzer/salesforce-code-analyzer/guides/config-custom.md canonical_url: https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/config-custom.html source_site: developer.salesforce.com content_type: documentation content_hash: 9540e07d09e5e6608623cde94c3bd80780a58bca2381e8837ecade72711990fc products: - Salesforce Code Analyzer --- # Customize the Configuration 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: - Configure top-level Code Analyzer properties, such as the location of the log files. See [Top-Level Customization Reference](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/config-toplevel.md) for details. - Override the properties of existing rules, such as their severity or tags. See [Engines](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/engines.md) for links to specific engine documentation and their rules. - Adjust engine properties, including adding custom rules. See [Engines](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/engines.md) for links to specific engine documentation, including their configuration. - Ignore Code Analyzer violations for specific files to reduce noise in scan results. Ignoring them reduces the time spent reviewing expected or acceptable patterns. **note:** 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. 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. ## Create and Examine the `code-analyzer.yml` File 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. ```bash sf code-analyzer config --output-file code-analyzer.yml ``` 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. ```yaml log_folder: /Users/john.doe/code-analyzer/logs ignores:  files:   - "**/utils.js" rules:  regex:   NoTrailingWhitespace:    severity: 2    disabled: true    tags: ["CodeFormat"]  eslint:   sort-vars:    severity: Info    tags: ["Recommended", "Suggestion"] suppressions:  disable_suppressions: false  "src/controllers/":   - rule_selector: "eslint:complexity,pmd:CyclomaticComplexity"    max_suppressed_violations: 50    reason: "Technical debt from v1.0 - tracked in JIRA-1234" engines:  eslint:   eslint_config_file: .eslintrc.json  regex:   custom_rules:    NoTodoComments:     regex: /\/\/\s*TODO\b/gi     file_extensions: [".cls", ".trigger"]     description: Prevents TODO comments from being in Apex code.     violation_message: Found a comment in an Apex file with a TODO statement.     severity: Moderate     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](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/suppress-violations.md#suppress-violations-in-a-file-or-folder) 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`. **tip:** 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 ## See How `code-analyzer.yml` Affects the Command Results 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: ```bash sf code-analyzer rules --rule-selector eslint:sort-vars ``` The command returns this information about the `eslint:sort-vars` rule: ```bash # Name Engine Severity Tag ─ ───────── ────── ──────────── ───────────────────────────────────── 1 sort-vars eslint 3 (Moderate) BestPractices, Javascript, Typescript ``` 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: ```bash # Name Engine Severity Tag ─ ───────── ────── ──────── ─────────────────────── 1 sort-vars eslint 5 (Info) Recommended, Suggestion ``` 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: ```bash sf code-analyzer rules --rule-selector regex:NoTodoComments ``` 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. ```bash sf code-analyzer rules --rule-selector regex:NoTodoComments --config-file ../code-analyzer.yml ``` The command now returns this output, which is exactly what is configured in the `code-analyzer.yml` file: ```bash # Name Engine Severity Tag ─ ────────────── ────── ──────────── ─────────────────────── 1 NoTodoComments regex 3 (Moderate) Recommended, CodeFormat ``` 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!