Change Request: Future of standard / xo style CLI #18800
Description
Up to date proposal in this comment below: #18800 (comment)
ESLint version
9.9.0
What problem do you want to solve?
standard has long used standard-engine to package itself up as a self-contained CLI, and prior to flat configs it came with two benefits:
- it avoided having all the plugins as peer dependencies (now solved by flat configs)
- it enabled running the rule set without any additional configuration, avoiding opening the door to possible endless rule discussions
standard-engine also came drawbacks:
- it needed custom editor integration rather than working out of the box with eslint-capable environments
In the ESLint 9 Flat Config version of standard (published as neostandard due to governance discussions) we aimed to skip standard-engine as Flat Configs essentially made it redundant, but it left us without a self-contained CLI, requiring config files which may encourage rule discussions and customisations, something we have been requested to solve neostandard/neostandard#2
Other similar tools have the same issue, such as eg. xo: xojs/xo#702 (comment)
Originally posted at neostandard/neostandard#33
What do you think is the correct solution?
I want to try and find a solution where people can use neostandard, xo etc without having to set up an eslint.config.js where they potentially open themselves up to extensions and modifications of the shared config.
See up to date proposal in this comment below: #18800 (comment)
Original thoughts, now outdated
It could eg be:neostandard,xobeing able to wrap the ESLint CLI and publish as their own CLI:s, resulting in egneostandard --semi --fix(I drafted on this in https://github.com/neostandard/neostandard/pull/2/files#diff-180b3d2af89416b99563fff8c37eb8ca1ef7591fc1ddd736b5dacf740ccd3760R87-R90)neostandard,xoshared configs being possible to configure for ESLint in some other way, eg:- (ignoring the name of the arguments)
eslint --shared-config=neostandard --shared-config-semi --fix - In
package.jsonadding something like:"eslint": { "shared-config": "neostandard", "shared-config-options": { "semi": true } },
- (ignoring the name of the arguments)
No matter the solution I think its key to have a solution that editors and other eslint-capable environments understand, avoiding the need to build custom integrations for eg. VSCode, as both standard and xo has done.
Participation
- I am willing to submit a pull request for this change.
Additional comments
I think the success of both standard and xo has shown that some people desire a tool that's less configurable by the users – delegating it completely to a third party.
With Flat Configs now solving the peer dependency need the need for standard-engine style solutions is less and working towards officially supporting "ESLint distributions" like standard and xo would be great and avoid having work duplicated across multiple VSCode extensions etc. – providing better and wider support for everyone.