Ignoring user settings when a local config file is present

[kachkaev]

I have started using CSpell as a local (in-project) linter, which I can run in CI via pnpm cspell .. I have also configured CSpell via [project]/cspell.config.yaml — this file is successfully picked by the command line and the VS Code extension.

While using the extension, I have noticed some discrepancies in linting results between the CLI and the editor. It turned out that the extension was mixing a project-level cspell.config.yaml with "cSpell.*" properties from my VS Code user’s settings.json. I did not expect this behavior and could not figure out how to permanently turn the mixing off.

Having a bit of experience with other VS Code extensions (Prettier, ESLint, MarkdownLint), I expect that a local config file is replacing instead of supplementing any config that has been defined in any VS Code settings. When project config is mixed with the user config, parity between VS Code output and CLI output cannot be guaranteed so the DX gets worse.

As a workaround, I have been able to mitigate the disparity by setting "cSpell.userWords": [] in [project]/.vscode/settings.json and by adding minWordLength: 3 to [project]/cspell.config.yaml. The first line prevented my VS Code user’s custom words from leaking into the project and the second line has matched the CLI with "cSpell.minWordLength": 3 for the VS Code user.

The number of CSpell options is quite large so my workaround is not reliable. Other project contributors will likely face other disparities over time. To mitigate that, we will have to iterate on both files and thus waste time understanding the discrepancies.

It would be great if CSpell extension worked similarly to Prettier, ESLint, MarkdownLint or TypeScript linters. When a local CSpell file is found, it should become the only source of truth for the config, so none of the user settings can change the feedback of the IDE. Thus, at any time, the list of errors seen in VS Code matches the list of errors seen in CI for everyone.

If a permanent switch is impossible, it’d be great to be able to set something like "cSpell.configMixing": false in [project]/.vscode/settings.json to at least limit the number of settings needed to achieve the parity. If a local project file is found, all VS Code’s settings should be ignored.

What do you think folks?

[Jason3S]

@kachkaev,

Thank you for the thoughtful request. You make a good point.

I have also seen other teams adding cspell.userWords to their .vscode/settings.json files.

This is going to require a bit of thought.

[Jason3S]

Fixed by #2868

I hope to release this in a week or two.

[kachkaev]

Great news @Jason3S 🎉

Looking at #2868, I see that cSpell.mergeCSpellSettings defaults to false. Do I understand correctly that merging will be disabled by default in an upcoming version? If so, it won't be necessary to do anything special in cspell.json, right? Even if this file is empty, VS Code settings are ignored and CSpell CLI fully matches IDE output, no matter what.

Just trying to understand if I need to update anything in the repos I help manage.

[Jason3S]

Some vscode settings still have an impact, these mostly have to do with user experience, like how often to spell check and how many errors to show.

The key thing is, that if a file is spell checked, the results should be the same as the command line tool.

• enabled - still allows the user to turn on/off the spell checker in vscode.
• enabledFiletypes - still allows the user to control which files are checked. Add "enabledFiletypes": ["*"] to cspell.json to override this.

I updated #2868 PR to better document this.

[Jason3S]

Even if this file is empty, VS Code settings are ignored and CSpell CLI fully matches IDE output, no matter what.

Yes. A cspell.json that is just {} will cause the vscode settings to be ignored.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.