ESLint Configuration Update in VSCode - support custom file names.

[saravanakumar2504]

We've successfully migrated our ESLint configuration from .eslintrc to the new flat config format, and it is functioning well within our CI/CD pipelines.

To integrate the new eslint.flat-config.js file with VSCode, we've updated our settings.json as follows:

{ "eslint.workingDirectories": [ "directory-1", "directory-2", "directory-3" ], "eslint.options": { "overrideConfigFile": "eslint.flat-config.js" }, "eslint.useFlatConfig": true // Other config }

However, due to the size of our monorepo and the complexity of the flat config with multiple file groups and overrides, we encounter an issue where changes to the ESLint config require a manual restart of the ESLint server in VSCode to take effect.

Question: How can we streamline this process to avoid manually restarting the ESLint server every time we update the configuration?

[dbaeumer]

The problem is different naming of the flat config file. Is it necessary that you use a name different than the standard name?

[saravanakumar2504]

"We've migrated from .eslintRc.js to a flat config by custom file name eslint.flat-config.js.
Our pipeline supports this change, but VSCode doesn't fully yet.

In. our pipeline we are pointing to ESLINT_USE_FLAT_CONFIG=true eslint -c eslint.flat-config.js
We're enabling flat config in VSCODE with a small group of developers to identify and fix any issues with flat config. Once everything works smoothly, we'll remove .eslintRc.js."

So the default one is we have follow this eslint.config.js right ?

[dbaeumer]

Yes, if you use the default one everything should work without a restart of the ESLint server.

[saravanakumar2504]

@dbaeumer : "I renamed eslint.flat-config.js to eslint.config.js for development purposes and removed the line"eslint.options": { "overrideConfigFile": "eslint.flat-config.js" }from .vscode/settings.json. However, I'm still experiencing the same behaviour where i need to restart eslint server so that i can see the updated rule in VSCODE"

[saravanakumar2504]

@dbaeumer : I found the root cause of my issue is my eslint.flat-config.js will look like below.

const test1 = require('./eslint.test1-flat-config.js');
const test2 = require('./eslint.test2-flat-config.js');

module.exports = [
	...test1.map((config) => ({
		...config,
		name: `test1 - configuration`,
	})),
	...test2.map((config) => ({
		...config,
		name: `test2 - configuration`,
	})),
];

So when i'm changing eslint.test1-flat-config.js or eslint.test2-flat-config.js the changes were not reflecting as our .vscode/settings.json has config of "eslint.options": { "overrideConfigFile": "eslint.flat-config.js" }

[saravanakumar2504]

I accidentally marked as completed and re-opened now

[dbaeumer]

There is not much I can do about that since I don't know the content of the eslint.flat-config.js file. The extension automatically does the right thing if the eslint.flat-config.js file changes.

[saravanakumar2504]

Thanks @dbaeumer for your reply. So the expectation is we have to keep all the configs inside single file named eslint.flat-config.js.

My case is we have splits our overrides into multiple files(test.eslint1.js, test.eslint2.js, test.eslint3.js) and integrated in eslint.flat-config.js. . So when changing in overrides is not impacting the vscode ide. I will try to create mock github and will share you the details later

[saravanakumar2504]

@dbaeumer : You can find the working example here.

I've cloned the sample repository here and forked it into my GitHub account. While everything works as expected with flat config linting, I'm facing an issue with importing linting rules as overrides from other files (e.g., globals/globalsWebPPLJs.mjs).

Specifically, when I update the no-console rule in globals/globalsWebPPLJs.mjs to error/warn/off,(which i imported in eslint.flat-config.js) VS Code doesn't recognize the change until I restart the ESLint server. In contrast, updating the rule directly in eslint.config.js is immediately recognized by the VS Code IDE.

This is the issue I'm encountering.

[dbaeumer]

All I can think of is adding config support so that users can define on which file changes the server should re-fetch the config.