Write ESLint RFC about solving CLI needs for neostandard, xo etc

[voxpelli]

standard-engine solved two problems:

• it avoided having to install all of the plugins directly, something that flat configs now solve
• it enabled one to run it as a standalone command, avoiding opening the doors to customization of rule sets and possible endless discussions that follows (DRAFT: CLI etc #2)

It also came with some drawbacks:

• needed custom editor integration rather than being plug and play with editors that support eslint (Editor integration #4)

What I would want to do is to:

Find an official solution together with the ESLint project, where we can officially bundle ESLint with our config and have it be exposed as a standalone non-configurable CLI.

That could enable editors etc to pick the bundled config without any custom integrations (I'm not very keen on going the route of standard and solving #4 by building new editor integrations 🙂) This could probably happen by eslint itself gaining the ability to pick up such a bundled configuration even when launched independently rather than through the standalone CLI (neostandard, xo etc)

To get this process started, an RFC to the ESLint project should be written.

Originally posted by @voxpelli in #16 (comment)

Also discussed in: xojs/xo#702 (comment)

[voxpelli]

Posted here: eslint/eslint#18800

Closing as done for now.

[voxpelli]

Keeping open to track progress

[voxpelli]

Feedback on eslint/eslint#18800 (comment) etc appreciated 🙏

[bcomnes]

Idea for a neostandard cli:

Rather than the old model used for standard, where a a parallel plugin ecosystem was required for editors and whatnot, the neostandard cli would just set up the underlying tools for neostandard use (generate eslint config, and any other eventually bundled tools like dprint or boom) and then run a check that they remain configure correctly, perhaps with a strict and loose option that allows and prohibits customization. This check could be run along side linting as desired.

[voxpelli]

@bcomnes Building on that I was pondering whether something like neostandard --ts (or maybe neostandard --ts --fix or neostandard --ts --check) could simply generate a temporary config file if no config exists (utilizing eg. tempy) and then invoke eslint --config /path/to/temp/file.js using eg. child_process.spawn()

One could then possibly also support eg. --format and some others by forwarding them to child_process.spawn() in a suitable way.

---

And when/if "eslint-preset": "neostandard" (eslint/eslint#18800 (comment)) gets supported we could add something similar to the "standard" key in standardjs and have the neostandard CLI skip the temporary file and it'll be enough for it to simply do the child_process.spawn()

(An "eslint-preset": "neostandard" should also mean that one would be able to do eslint -c neostandard or similar to bypass eslint.config.js and delegate the config generation to a module)

[bcomnes]

It could also facilitate a multi-tool future if that is ever forced (eslint + dprint for example).

[jerome-benoit]

Handling current flat configurations extended with neostandard (last) with the CLI can also help potential users to answer the question: "What will be the impact of migrating a code base to neostandard?" with no configuration fuzz.

[voxpelli]

I keep trying to find ways to express my ideas in a way that conveys it in an understandable way: eslint/eslint#18800 (comment)

[voxpelli]

@wesleytodd I give up on trying to get through, I’m apparently not able to express it in a way that makes sense, or I focused on the wrong aspect initially and that’s what got stuck in people’s mind. Feel free to give it a try.

I wonder if it would be easier to try to make PR:s to eg the VSCode ESLint extension that introduces a separate tool-specific configuration lookup.

It would take more effort and be less flexible than doing it as an extension to the ESLint configuration system, but 🤷

I will however not be able to spend any time on this for the rest of the year – I have spent too much time on unpaid projects and all I get in return is massive pushback when I try to help out, and that takes some time to recover from that and I need to spend all of that time on projects that actually helps me pay my rent.

[voxpelli]

Another option would be to fork eslint and maintain it separately with no other changes but a patch for this, and have users use it as "eslint": "npm:@neostandard/eslint@^9.0.0"

That way it would work automatically in eg the VSCode extension I believe

[bcomnes]

I barely have enough time for this project let alone tracking an overactive upstream project like eslint. Let's just ship our own helper cli to help with config setup.

[voxpelli]

Well do something like what @bcomnes suggested, when someone has time for it, but I’m going to close this one as I rather put this whole thing behind me

[voxpelli]

Replaced by: #205