Vscode-eslint: Automatic detection of preconfigured eslint packages

[LinusU]

Feature Request: I would love to have automatic detection of the most common "packaged eslint" flavors, specifically standard and xo.

I often contribute to many packages which uses both Standard and XO. My current setup is just to have the StandardJS package installed in VS Code, since that is what I use for my own projects. But that makes basically every line being marked red when contributing to a package using the XO eslint package.

My idea of the ultimate setup would be if this module could detect whenever one of the preconfigured eslint packages is being used in a project, and then load up that config.

In practice, I think this would be easiest to achieve by maintaining a list of packages to look for in the devDependencies, and a corresponding eslint-config for that package.

const eslintPackages = new Map([
  ['happiness', 'eslint-config-happiness'],
  ['semistandard', 'eslint-config-semistandard'],
  ['standard', 'eslint-config-standard'],
  ['xo', 'eslint-config-xo']
])

If this is something that is wanted, I would be happy to help implement it. If you think that this is out of scope for this module, I would totally understand that.

Thanks!

[dbaeumer]

@LinusU I am actually not fully understanding what you want to achieve. Easing the eslint setup? If so shouldn't this be something that should go into ESLint itself then into this extension. I tried hard to not add any features on top of ESLint in this extension mainly because the extension should produce the same result and errors when run or whether eslint is run from the command line.

[LinusU]

I am actually not fully understanding what you want to achieve. Easing the eslint setup?

Not really. My specific problem is that I contribute to a lot of different open source projects, all using their own setup of linting.

The two absolute most common cases are that the package is using either standard or xo. Some projects, especially larger ones, also use a custom eslint config.

My goal is for this module to be able to understand when I'm opening a project that uses standard or xo, and for the correct eslint config be loaded, and linting be shown directly in VS Code.

If so shouldn't this be something that should go into ESLint itself then into this extension.

I don't think so, since those packages (e.g. standard and xo) themselves depend on ESLint. They are basically a bundle with ESLint and a config. Their goal is to reduce the friction when managing many projects, since you can just import that one package and be done with it.

I tried hard to not add any features on top of ESLint in this extension mainly because the extension should produce the same result and errors when run or whether eslint is run from the command line.

I understand this, but I don't think that this is extending ESLint. It's more about where to look for the config. Basically, I want to run eslint -c standard . instead of eslint -c ./eslintrc.json ..

[dbaeumer]

I still have problems understanding it.

My goal is for this module to be able to understand when I'm opening a project that uses standard or xo, and for the correct eslint config be loaded, and linting be shown directly in VS Code.

Would the project that uses standard have corresponding eslintrc.json file (same for the project using xo). Then this should work out of the box.

If you have two eslintrc.json files outside of the project folder you can always tell the extension via the options setting which one to use:

"eslint.options.configFile": "path to my config file"

How would someone then run eslint on the command line. To my knowledge eslint -c standard . is not supported.

[LinusU]

Would the project that uses standard have corresponding eslintrc.json file (same for the project using xo). Then this should work out of the box.

The problem is that they don't have an eslintrc.json, that is what's seen as the "benefit" of using standard or xo. All you have to do is add standard (or xo) as a devDependency, and add standard (or xo) to your test-script.

Here is an example of how it works, there are no other files required: https://github.com/ctrl-alt-deseat/ctrlpanel-hkdf/blob/a5975c26e0184fad0af4d7e6ba375a3b70fbe004/package.json#L7-L15

If you have two eslintrc.json files outside of the project folder you can always tell the extension via the options setting which one to use:

The reason why I cannot use an option is that different projects are using different configs. Since I work on many different projects of which I have no control over, my feature request is to be able to automatically detect this.

How would someone then run ESLint on the command line. To my knowledge eslint -c standard . is not supported.

eslint -c standard . is supported 🙌, it's a shorthand for eslint -c eslint-config-standard ., which is a shorthand for eslint -c node_modules/eslint-config-standard/eslintrc.json ..

See documentation here: https://eslint.org/docs/user-guide/command-line-interface#-c---config

I do hope I'm making myself clear ☺️ basically, I want something like this:

+const packageInfo = loadPackageJson()
+
+if (packageInfo.devDependencies.standard) {
+  run('eslint', ['-c', 'standard', '.'])
+} else {
   run('eslint', ['.'])
+}

(very much pseudo-code 😄)

[dbaeumer]

Thanks for the nice explanation. I wasn't aware of eslint -c standard. The ESLint extension however doesn't spawn an eslint process on every linting run. It basically uses eslint as a library and programs against the Node API provided (https://eslint.org/docs/developer-guide/nodejs-api#cliengine). From reading through the documentation your approach should be doable using the configFile option. To test this you could set `"eslint.options.configFile": "standard" and see what happens.

I am open to a PR that implements this be checking the content of the package.json file.

[vscodebot[bot]]

This feature request will not be considered in the next 6-12 months and has been closed to keep the number of issues we have to maintain manageable. See also our issue reporting guidelines.

Thanks for your understanding and happy coding!

[cyrilchapon]

I can expand on this use-case.
I'm contributing to different environments to, sometimes with custom eslint; often with standard or even standardx.

Having to literally disable eslint-vscode and enable standard-vscode is a real pain; as neither of them understand the other