Configuring Code Analyzer Skill

Overview

Ecosystem: This skill is part of a 3-skill Code Analyzer suite — dx-code-analyzer-run (scans & results) · dx-code-analyzer-configure (setup, config, CI/CD) · dx-code-analyzer-custom-rule-create (custom rule authoring).

Scope

• Checking prerequisites (sf CLI, Java, Node.js, Python, org auth)
• Installing/updating the Code Analyzer plugin
• Creating code-analyzer.yml if it doesn't exist
• Editing code-analyzer.yml for all configuration changes
• Engine settings, rule overrides, ignore patterns, suppressions
• CI/CD pipeline setup (GitHub Actions, Jenkins, etc.)
• Environment validation and troubleshooting

• Running scans → use dx-code-analyzer-run skill
• Fixing violations, explaining rules, suppression management → use dx-code-analyzer-run skill
• Creating custom rules → use dx-code-analyzer-custom-rule-create skill

Tool Usage Rules

Core Principle: YAML Only When Customizing

• Do NOT create code-analyzer.yml proactively — only when user asks to change something
• Do NOT duplicate built-in defaults — only write entries that intentionally override behavior
• Always place at project root — where sfdx-project.json or sf-project.json lives
• The CLI auto-discovers it — sf code-analyzer run from project root automatically picks up code-analyzer.yml in that directory. No --config-file flag needed.
• User says "configure code analyzer" with no specifics? → Ask what they want to customize. Don't create an empty or boilerplate file.

1. User requests a customization (e.g., "disable PMD", "ignore test files", "increase SFGE memory")
2. Check if code-analyzer.yml exists at project root
3. If NO → create it at project root with ONLY the requested override
4. If YES → read it, then edit in the requested change
5. Validate with sf code-analyzer config

Step 1: Understand Intent and Map to Config Sections

1. Parse what they want — may be one thing or many things combined
2. Map each request to the correct section(s) of code-analyzer.yml
3. Create the file if it doesn't exist, then apply all changes

The code-analyzer.yml Structure (what you can write/edit)

config_root: .                    # Root for relative path resolution
log_folder: <path>                # Where logs are written
log_level: <1-5>                  # 1=Error, 2=Warn, 3=Info, 4=Debug, 5=Fine

ignores:                          # Files/folders excluded from scanning
  files: [<glob patterns>]

engines:                          # Per-engine settings
  <engine_name>:
    disable_engine: <bool>
    <engine_specific_keys>: ...

rules:                            # Per-rule overrides
  <engine_name>:
    <rule_name>:
      severity: <1-5>
      tags: [<strings>]
      disabled: <bool>

suppressions:                     # Bulk suppression configuration
  disable_suppressions: <bool>
  "<file_or_folder_path>":
    - rule_selector: "<selector>"
      max_suppressed_violations: <number|null>
      reason: "<why>"

Mapping Principle

File Existence Decision

ls code-analyzer.yml code-analyzer.yaml 2>/dev/null

• File does NOT exist → Create it at project root with ONLY the user's requested override(s)
• File exists → Read it, then Edit to add/modify the requested section(s)

Rule Name Resolution — ALWAYS Before Writing YAML

• "Disable the ApexDoc rule" → lookup confirms ApexDoc (engine: pmd)
• "Demote no-console to low" → lookup confirms no-console (engine: eslint)
• "Make CRUD violations critical" → lookup confirms ApexCRUDViolation (engine: pmd)
• "Turn off the hardcoded values check" → lookup finds @salesforce-ux/slds/no-hardcoded-values-slds2 (engine: eslint)
• "Disable the injection rule" → multiple matches possible → ask user which one

Handling Combined/Complex Requests

• "Disable PMD's ApexDoc rule and make CRUD violations critical" → edit two entries under rules.pmd
• "Exclude test files and vendor code, and increase SFGE memory" → edit ignores.files + engines.sfge.java_max_heap_size
• "Set up code analyzer with only ESLint and PMD, ignore node_modules" → create file with engines (disable others) + ignores
• "Make all security rules severity 1" → look up rules via sf code-analyzer rules --rule-selector Security, then override each
• "Configure code analyzer" (no specifics) → ask user what they want to customize before creating any file

Quick Reference: Common Requests → Config Output

Step 2: Check Prerequisites and Install

sf --version 2>&1                                    # sf CLI
sf plugins --core 2>&1 | grep -i "code-analyzer"    # Plugin
java -version 2>&1                                   # Java 11+ (PMD, CPD, SFGE)
node --version 2>&1                                  # Node 18+ (ESLint, RetireJS)
python3 --version 2>&1                               # Python 3 (Flow engine)

npm install -g @salesforce/cli                       # sf CLI
sf plugins install @salesforce/plugin-code-analyzer  # Code Analyzer plugin

Step 2A: Diagnose and Fix a Broken Setup

• Never search for binaries (which, find, ls /opt/homebrew/bin/)
• Never use sfdx as a workaround — only sf
• Fix layer by layer: CLI → Plugin → Engine deps → verify scan
• Give user ONE command at a time, wait for confirmation before continuing
• After fix succeeds, proceed to run the full scan automatically

Step 3: Create or Edit code-analyzer.yml

Creating (file doesn't exist)

Note: The script exits with an error if code-analyzer.yml already exists. Delete the existing file first if you need to regenerate.

• For Apex-only projects, read <skill_dir>/examples/apex-project-config.yml
• For LWC-only projects, read <skill_dir>/examples/lwc-project-config.yml
• For full-stack (Apex + LWC + Flows), read <skill_dir>/examples/fullstack-project-config.yml

# Example: user said "ignore test files and increase SFGE memory"
# → Write to project root (where sfdx-project.json lives):

ignores:
  files:
    - "**/test/**"
    - "**/__tests__/**"

engines:
  sfge:
    java_max_heap_size: "4g"

Editing (file already exists)

After any create/edit, validate:

sf code-analyzer config

If user says "configure code analyzer" with no specifics

Step 4: Enable/Disable Engines

engines:
  pmd:
    disable_engine: true       # Disable PMD
  eslint:
    disable_engine: false      # Enable ESLint (default)

sf code-analyzer config --config-file code-analyzer.yml

Step 5: Ignore Patterns

ignores:
  files:
    - "**/node_modules/**"
    - "**/.sfdx/**"
    - "**/.sf/**"
    - "**/vendor/**"
    - "**/*.min.js"

Step 6: Rule Overrides

rules:
  pmd:
    ApexCRUDViolation:
      severity: 1              # Promote to Critical
    AvoidGlobalModifier:
      disabled: true           # Turn off entirely
    ApexDoc:
      severity: 5              # Demote to Info
      tags: ["Documentation"]
  eslint:
    no-console:
      severity: 4              # Demote to Low
    no-unused-vars:
      severity: 2              # Promote to High

6.1 Rule Name Resolution (Fuzzy Matching)

sf code-analyzer rules --rule-selector all 2>&1 | grep -i "<USER_KEYWORD>"

• 1 match → use that exact name + its engine for the YAML path
• Multiple matches → ask user which one they meant
• 0 matches → try broader keywords or inform user

Step 7: Engine-Specific Settings

engines:
  sfge:
    java_max_heap_size: "4g"      # <200 classes→"2g", 200-500→"4g", 500+→"6g"/"8g"
    java_thread_count: 4
    java_thread_timeout: 900000
  eslint:
    auto_discover_eslint_config: true    # Use project's own ESLint config
    eslint_config_file: "./eslint.config.mjs"
  pmd:
    custom_rulesets: ["./config/custom-pmd-rules.xml"]
    java_classpath_entries: ["./lib/custom-rules.jar"]
  cpd:
    minimum_tokens: { apex: 100, javascript: 100 }
  apexguru:
    target_org: "my-org-alias"
  flow:
    python_command: "python3"
  # regex.custom_rules — use the dx-code-analyzer-custom-rule-create skill to create these.
  # Never hand-write regex patterns into code-analyzer.yml: quotes/backslashes
  # inside YAML cause parsing failures. The create-regex-rule.js script handles
  # serialization correctly and must always be used for regex rule creation.

Step 8: CI/CD Pipeline Setup

Step 9: View Current Configuration

sf code-analyzer config                               # Show effective config
sf code-analyzer config --rule-selector pmd:Security  # Specific rules
sf code-analyzer config --include-unmodified-rules    # All defaults

Cross-Skill Integration

When dx-code-analyzer-run delegates HERE:

1. Run the diagnose and fix flow (Step 2A) — find what's broken, fix it
2. After everything works, automatically proceed to run the scan — do not stop and ask. The user's original intent was to scan.
3. Hand execution back to dx-code-analyzer-run behavior (build command, execute, parse results).

When THIS skill hands off to dx-code-analyzer-run:

When THIS skill hands off to dx-code-analyzer-custom-rule-create:

When user intent spans BOTH skills:

Rules / Constraints

Gotchas

Reference File Index