Support for ESLint 8

[EvHaus]

Issue Type

Bug

Issue Description

ESLint 8 is out now, and unfortunately linter-eslint does not support is as it uses the now-deprecated CLIEngine property. Migration docs can be found here.

Logging this task to capture the work that will be needed to ensure ESLint 8 can be supported.

Bug Checklist

• Restart Atom
• Verify the eslint CLI gives the proper result, while linter-eslint does not
• Paste the output of the Linter Eslint: Debug command from the Command Palette below

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined

[MRDGH2821]

Any update on this ?

[UziTech]

See #1442

[savetheclocktower]

The approach we seemed to land on in #1442 is the one I'd vote for: a new linter-eslint-something pakage hosted by the AtomLinter organization, where “something” perhaps indicates that this is only for ESLint v7 and greater. (Maybe linter-eslint-modern or something, except that's awful.) That way it can have its own distinct settings and doesn't have to preserve expected behavior that may only have been possible with the now-removed CLIEngine class.

Since the new package would spawn a worker process that needs to use the user's own version of Node, it would add a setting for nodeBin (and perhaps eslintModulePath) so that people could define those if node isn't in their path, or isn't the correct version. People who use NVM and need per-project versions of those settings could use project-config or atomic-managment, or could define them via a .linter-eslint file.

Once that package exists, linter-eslint could be updated to notify the user whenever a project is using ESLint v8 or greater, and prompt them to install the new package if it's not already present. Since both linter-eslint and linter-eslint-redux (ugh, that's even worse) could both successfully lint using v7 — when CLIEngine was deprecated but not yet removed — linter-eslint would probably want to skip linting when it sees a v7 version of ESLint, but only if it knows that the other package is installed.

I'd be happy to help out with this if it would be welcomed; I've got a preliminary version of the find-the-user's-version-of-node code in a local package that's mainly just a port of @scagood's proof-of-concept gist.

[UziTech]

@savetheclocktower I created AtomLinter/linter-eslint-node and invited you as a maintainer. If you want to create the initial version I can help you wherever you need.

[UziTech]

We just released linter-eslint-node which should work with eslint v8. We created a new package for this because it required many breaking changes and we want people using linter-eslint successfully with older versions of eslint to be able to continue using it.