Salesforce Code Analyzer Code Inspection seems to ignore the the specified config file

[Patrick Visniewski]

Basically I've customized a config yaml file for use in a Github workflow or running the SF code analyzer from the command line. But when I try to use that same config file with the "Salesforce Code Analyzer" inspection I get very different results.

I do this

1. right click in the text editor for a file
2. select Analyze
3. select Inspect Code...
4. then in the popup I configure the "Inspection Profile" or select one that is configured as follows
   1. uncheck everything but "Salesforce Code Analyzer" in the "Salesforce" group
   2. for this selection I set one option: The "Configuration file"
   3. I set this to a config yaml file in the root of my SF project
5. I run the scan

The results do not match the severities or rules specified in the yaml file and the extra PMD xml file that goes with it.

In comparison we have github workflow that runs: 

sf code-analyzer run --config-file=exact_copy_of_the_config.yml ...

In the workflow everything works right. The are multiple items that are found for the same tested file that are not found by IDEA

Similarly if I run the code analyzer by hand in the IDEA terminal using the same config file, it all works as expected.

Can this be fixed or am I somehow doing something wrong or have the wrong expectation that the "Salesforce Code Analyzer" in the UI is the same as 

sf code-analyzer run...

?

Or how can I provide debugging for this?

This happens in the latest version of IDEA plus IC2 on both Win11 and Mac.

IntelliJ IDEA 2025.2.4 (Ultimate Edition)
IC2 2.3.8.4

[Scott]

My guess is that you've enbled the Ignore redundant rules option for that inspection, no? If that's the case, IC will customize your provided ruleset file to disable the PMD, CPD, and ESLint engines for Code Analyzer if the respective first-class code inspections are enabled. You can find more information on that here:

https://illuminatedcloud.blogspot.com/2025/05/2359-release-notes.html

When you run Salesforce Code Analyzer from within IC without a config file, it uses the default config.

If you have that disabled option disabled and aren't seeing the same results as when you run it externally against the same config file, please enable debug logging for Salesforce Code Analyzer, reproduce the issue, and take look at how it's being executed in idea.log. I'm happy to review the log as well, of course, and let you know what I see.

Regards,

Scott Wells

[Scott]

I should say "you haven't disabled the Ignore redundant rules option" as it's enabled by default. It's not something you would have had to explicitly opt into. The recommendation is the same, though. Disable that option while specifying your config file and see if you don't get the same results.

Regards,

Scott Wells

[Patrick Visniewski]

Unfortunately I have tried with and without ignore redundant rules. It doesn't make a difference.

[Patrick Visniewski]

Ok here is the logging from a run on a JS file too. You can see where it it calls the code analyzer with the config file

C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json

no clue why it would be different 

Also IMO the "ignore redundant rules" would have to broken if it disabled ALL versions of a rule rather than "ALL but 1 version of a rule" 

In one case, for this specific file, there is a redundant rule in that it is both in ESLINT and PMD. If I tell it to ignore redundant I would expect the correct behavior to be to run one of the 2 rules but not both.

Plus there are a few other violations that are NOT redundant unless there is some weird definition of what it decides it "redundant"

2025-11-13 19:03:35,043 [3499257]   FINE - #com.illuminatedcloud.intellij.codeAnalyzer.inspection.codeAnalyzer.SalesforceCodeAnalyzerExternalAnnotator - Using cached response for 'main/default/lwc/proProjectCreate/proProjectCreate.js'.
2025-11-13 19:03:43,007 [3507221]   INFO - #c.i.c.e.GlobalInspectionContextBase - Code inspection started
2025-11-13 19:03:43,078 [3507292]   FINE - #com.illuminatedcloud.intellij.util.CommandLineUtil - Running command line: 'C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json' from working directory: 'C:\idea\SomeSFProject'.
2025-11-13 19:03:43,091 [3507305]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 1.
2025-11-13 19:03:44,091 [3508305]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 2.
2025-11-13 19:03:45,092 [3509306]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 3.
2025-11-13 19:03:46,092 [3510306]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 4.
2025-11-13 19:03:46,365 [3510579]   INFO - #c.i.c.e.GlobalInspectionContextBase - Cancelling inspection progress
2025-11-13 19:03:47,092 [3511306]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 5.
2025-11-13 19:03:48,093 [3512307]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 6.
2025-11-13 19:03:49,094 [3513308]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 7.
2025-11-13 19:03:50,095 [3514309]   FINE - #com.illuminatedcloud.intellij.util.VariableLengthPollingInterval - C:/Program Files/sf/bin/sf.cmd code-analyzer run -c sf_code_analyzer_config.yml -t force-app/main/default/lwc/proProjectCreate/proProjectCreate.js -f C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json: Using polling interval 1000 ms for polling iteration 8.
2025-11-13 19:03:51,095 [3515309]   FINE - #com.illuminatedcloud.intellij.util.CommandLineUtil - Returning command-line response: CommandLineResponse{exitCode=0, output='
Streaming logs in real time to:
    C:\Users\someusername\AppData\Local\Temp\sfca-2025_11_13_19_03_46_306.log


=== Summary

Found 0 violations.

Results written to:
    C:/Users/someusername/AppData/Local/Temp/SomeSFProject-proProjectCreate.js-results.json

Additional log information written to:
    C:\Users\someusername\AppData\Local\Temp\sfca-2025_11_13_19_03_46_306.log
', error='Selecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 0%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 20%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 40%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 42%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 43%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 55%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 56%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 57%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 58%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 59%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 60%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 61%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 67%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 81%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 82%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 95%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 97%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 99%; Elapsed time: 0sSelecting rules... Eligible engines: retire-js, regex, eslint, pmd, cpd; Completion: 100%; Elapsed time: 0sSelecting rules... done.
Executing rules... 0 of 1 engines finished after 0s.
- retire-js at 0% completion.Executing rules... 0 of 2 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.Executing rules... 0 of 3 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.
- eslint at 0% completion.Executing rules... 0 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.
- eslint at 0% completion.
- cpd at 0% completion.Executing rules... 0 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.
- eslint at 0% completion.
- cpd at 2% completion.Executing rules... 0 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.
- eslint at 0% completion.
- cpd at 5% completion.Executing rules... 0 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 0% completion.
- eslint at 0% completion.
- cpd at 9.65% completion.Executing rules... 1 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 9.65% completion.Executing rules... 1 of 4 engines finished after 0s.
- retire-js at 0% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 14.3% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 14.3% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 32.9% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 51.5% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 70.1% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 88.7% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 93.35% completion.Executing rules... 2 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 98% completion.Executing rules... 3 of 4 engines finished after 0s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 100% completion.Executing rules... 3 of 4 engines finished after 1s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 0% completion.
- cpd at 100% completion.Executing rules... 3 of 4 engines finished after 1s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 95% completion.
- cpd at 100% completion.Executing rules... 4 of 4 engines finished after 1s.
- retire-js at 100% completion.
- regex at 100% completion.
- eslint at 100% completion.
- cpd at 100% completion.Executing rules... done. Executed rules from retire-js, regex, eslint, cpd.
', duration=8017}
2025-11-13 19:03:51,096 [3515310]   INFO - #c.i.c.e.GlobalJavaInspectionContextImpl - Processing external usages finished in 0 ms
2025-11-13 19:03:51,104 [3515318]   INFO - #c.i.c.e.GlobalInspectionContextImpl - Code inspection finished. Took 8095 ms
2025-11-13 19:03:51,116 [3515330]   INFO - #c.i.c.e.GlobalInspectionContextBase - Cancelling inspection progress
2025-11-13 19:04:00,572 [3524786]   INFO - #c.i.w.i.i.j.s.JpsGlobalModelSynchronizerImpl - Saving global entities com.intellij.platform.workspace.jps.entities.SdkEntity to files
2025-11-13 19:04:00,574 [3524788]   INFO - #c.i.w.i.i.j.s.JpsGlobalModelSynchronizerImpl - Saving global entities com.intellij.platform.workspace.jps.entities.LibraryEntity to files
2025-11-13 19:04:00,643 [3524857]   INFO - #c.i.c.ComponentStoreImpl - Saving Project(name=pro_dev, containerState=COMPONENT_CREATED, componentStore=C:\idea\pro_dev)DockManager took 24 ms
2025-11-13 19:04:00,644 [3524858]   INFO - #c.i.c.ComponentStoreImpl - Saving Project(name=SomeSFProject, containerState=COMPONENT_CREATED, componentStore=C:\idea\SomeSFProject)DockManager took 28 ms, ProjectView took 27 ms
2025-11-13 19:04:00,956 [3525170]   INFO - #c.i.c.ComponentStoreImpl - Saving appCompletionMLRankingSettings took 39 ms

[Scott]

The Ignore redundant rules option is perhaps misnamed as it disables entire Salesforce Code Analyzer engines -- not specific rules -- if those engines are also enabled as first-class IDE inspections. It's obviously critically important that the intersecting engines are configured identically between the IDE's inspection and the Salesforce Code Analyzer config file, of course, or the results will diverge. It was named that because it followed the similar pattern and option established with IC's PMD Saleforce inspection where there are PMD rules that are already modeled as first-class IDE inspections, e.g., unused declaration detection and ApexDoc validation.

It sounds like you're seeing IC running Salesforce Code Analyzer as expected with the correct path to the config file. IC does remove the output file after loading it, but you can certainly run the exact same command-line that IC is running and see if the results are what you'd expect. If not, what are the differences in how it gets executed by IC vs. elsewhere, if any? If so, are there things that are being lost by IC between the outout file and what's displayed in the IDE? Can you provide a concrete way to reproduce that behavior if so?

Note that it's getting a bit late in my evening here, so I probably won't be albe to respond further until tomorrow, but please feel free to share your findings and answers to these questions and I'll be happy to dig in further.

Regards,

Scott Wells

[Patrick Visniewski]

I already wrote in some detail exactly how I reproduce this!

What was not "concrete" about that first post?

If instead you mean "it doesn't happen to you but does to me" my details are still "concrete" details!!

How about you explain what you might have done different testing this to so that it "just works" always for you!!

It's way too late for me already to be going doing this rabbit hole.

Now I'm getting weird results trying out tons of different variations.... I'm so sick of this not working right at this point.

The only place this file isn't working for me is in IC2. VS Code accepts the config file too but it does a horrible job of highlighting and reporting issues compared to IDEA

[Patrick Visniewski]

Ok now another issue has cropped up. Or maybe not cropped up, but I just noticed it: The code-analyzer is not running the PMD engine at all.

Whether or not I do it from IC2 or from the command line....

So for example if I run this

sf code-analyzer run --config-file=sf_code_analyzer_config.yml --output-file=results.csv --output-file=results.json --target=force-app\main\default\lwc\proProjectDetails\proProjectDetails.js

it does not run PMD

If I run this, it does run PMD

sf code-analyzer run --config-file=sf_code_analyzer_config.yml --output-file=results.csv --output-file=results.json --target=force-app\main\default\lwc\proProjectDetails\proProjectDetails.js -r 1 -r 2

I would guess that IC2 does not use this rule selector flag to limit severities but 

Do you know if for some reason the code-analyzer normally skips PMD for JS files?

I have noticed that specifying the rule selector flag caused the analyzer to run the graph engine which takes a huge amount of time, so I just disabled it in the config file.

My guess is that this is in fact a problem with the analyzer running different engines or not running them under certain circumstances.

Also if instead I use the severity threshold flag instead of rule selectors, it also does not run PMD. unfortunately I want PMD to run against JS files or I guess I just need a list of ALL the eslint rules possible so I can set the severity we use for our org.

Thank you Salesforce....

Sorry about the frustration but this has been happening for awhile and the only place I could not specify a rule selector is in IC2. So it is the only place I saw the difference.

V$ code does have an option to set rule selectors hence why it "worked" there as well....

[Patrick Visniewski]

Last comment:

The Code Analyzer config file does NOT let you exclude rules.

So the way IC2 is setup without an option for rule selectors means you have no choice but to run all rules for the enabled and selected engines.

I found out the hard way that removing a rule from an engine section in the YAML file does not stop the rule from being run. The YAML file just lets you override the severity and configure some traits about the engines.

It does not let you pick and choose which rules to run. I have this confirmed via a case with SF as well.

Also note that in the PMD section you can specify a custom rules file for PMD. This however also does not seem to allow you to pick and choose rules. It just lets you configure details about the rules.

We run their analyzer with a PMD file and have removed all the rules from it except the ones we wanted to tweak and all removed rules still get run by the analyzer. 

However, it might possibly let you create new rules, but I kind of doubt it will. But I'm not sure either way and have no intention of trying out this scenario to find out.

So if you are looking for analyzer feature completeness you probably want to add an additional config dialog field that would allow the user to specify a rules selector or multiple rules selectors sort of like how the V$ Code extension does.

However be aware of this added behavior where all the enabled engines get run if you do specify any rule selectors. This is a problem because it forces the Graph Engine to run. This engine runs really slowly. I have let a scan run for multiple hours and it never completed.

As a result of the previous case, they did take the suggestion to their dev team to allow disabling rules in the YAML file but there is not guarantee that the dev team will implement this. 

Basically I created a mostly complete list of rules in the YAML file then commented one out of the rules in the file. And then noticed that the rule still ran. That's when we opened a case with SF over the issue.

[Scott]

Trying to catch up on all of this. If I'm understanding correctly, there are two primary issues (or at least unexpected behaviors) here:

1. The Salesforce Code Analyzer config file is not authoritative in terms of engine rule configuration and is really an incomplete overlay over the engine's actual configuration file, e.g., PMD's ruleset or ESLint's config file. For the best/most reliable results, you should ensure that Code Analyzer is using the engine's config files -- whether found implicitly or specified explicitly -- and if you have the corresponding code inspections enabled in IC, those inspections should be using the exact same config files.
2. It seems that Salesforce Code Analyzer may not run certain rules without rule selectors being specified explicitly in the command-line invocation. I haven't verified that myself yet, but if that's the case, perhaps IC should specify "--rule-selector all" explicitly when it executes Code Analyzer.

Does that seem to capture your findings here? If not, please let me know what I've missed.

Regards,

Scott Wells

[Patrick Visniewski]

#1 is definitely the case. If a rule is not listed in the config file, but it is normally run under those circumstances, then it will still run.

The config file also has no flag to disable a rule and per the point above commenting out or removing a rule that runs from the config file does NOT stop it from running.

The same holds true if you specify an optional PMD.xml file and leave out rules. The rules left out of it will still be run.

The config yaml and the pmd config files together seem to just adjust details about each rule but have no control over whether or not a rule is run.

#2 is actually more like "using a rule selector CLI flag causes the analyzer to run all enabled engines if the rule selector applies at all to that engine"

Unfortunately for me, when I phrase #2 this way it seems like it sort of makes sense that it works this way, but sort of does not make sense based on the case I mention below.

In this case I used the selector to run all sev1 and sev2 rules. And even though the Graph Engine did not run normally, it ran in this case.

So for example

Here is where I got confused about the rule selector flag:

running to following does not run all engines - it skips the graph engine and PMD and anything else the config might disable

sf code-analyzer run -w . -c some_config.yml -t some_lwc_controller.js

running the runs all engines enabled in the config file that have a sev1 or sev2 rule

sf code-analyzer run -w . -c some_config.yml -t some_lwc_controller.js -r 1 -r 2

I would hope that at least if you specify says eslint rule with -r then it would JUST run that one rule but I do not know for sure if that is the case and haven't had a use case yet where I needed this. So I cannot say for sure.

[Scott]

Okay. Regarding #1, I don’t think there’s anything to change in IC. Basically it’s going to be important that the .yml config file is set up properly alongside the referenced engine config files, and if Ignore redundant rules is enabled, that the corresponding IDE inspection for a given engine is using the same config file. Otherwise things are going to diverge.

Regarding #2, I’m unclear as to whether there’s anything to change in how IC executes Salesforce Code Analyzer. IC doesn’t execute it for any specific engine or rule, just for the selected .yml config file. That’s true whether it’s running for only one file as an external annotator or for a set of files as a bulk inspection. Based on our prior exchange here, it sounded like perhaps it should always include --rule-selector all, but based on your most recent response, does that still sound right? Does execution with those args address the issue you’d described previously? Sorry for the confusion.

Regards,
Scott Wells

​