Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use ESLint instead of CLIEngine when available #128

Merged
merged 1 commit into from
Sep 22, 2021
Merged

Conversation

SimenB
Copy link
Member

@SimenB SimenB commented Sep 17, 2021

BREAKING CHANGE: Using ESLint might need different configuration
options. See https://eslint.org/docs/developer-guide/nodejs-api#parameters

CLIEngine is deprecated in ESLint v7 and removed entirely in ESLint v8, replaced by ESLint.

Landing this might give us support for ESLint v8 (#123) without changing anything more (although peer dep might still warn)

module.exports = {
cliOptions: {
global: ['hello'],
// `ESLint` requires this to be an object, not an array
global: ESLint ? { hello: true } : ['hello'],
Copy link
Member Author

@SimenB SimenB Sep 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is main reason I think this is a breaking change. While it's easy enough to normalize this specific field, there's probably others we'd miss - cleaner to just make a breaking change

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking about it, #125 might be considered breaking as well, if people previously ignored an engine warning and used this package on node 6. I don't consider it a breaking change, but bundling these together in a new major removes any ambiguity 🤷

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems pretty valuable to try to support both eslint 8 and < 8 at the same time

Copy link
Member Author

@SimenB SimenB Sep 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, but I don't think it's our responsibility to coerce user input into the correct type. Consumers should configure the the version of ESLint they choose to use correctly.

(I know we do some coercion already, so I'm also fine with special casing globals so our tests are happy. I'd still consider this a breaking change since it's a moving target though)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh true, fair point - i think it’s 100% fine if a user switches to eslint 8, and this runner breaks until they also fix their configuration (altho hopefully they get a very clear error message)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the error message from eslint is pretty good 👍 Specifically in this case if I leave it as an array

ESLint configuration in CLIOptions is invalid:
      - Property "globals" is the wrong type (expected object but got `["hello"]`).

@@ -1,6 +1,9 @@
{
"extends": ["airbnb-base", "prettier"],
"plugins": ["prettier", "jest"],
"parserOptions": {
"ecmaVersion": 11
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needed for optional chaining (babel transpiles it away)

BREAKING CHANGE: Using `ESLint` might need different configuration
options. See https://eslint.org/docs/developer-guide/nodejs-api#parameters
@@ -26,7 +26,8 @@
"dependencies": {
"chalk": "^3.0.0",
"cosmiconfig": "^6.0.0",
"create-jest-runner": "^0.6.0"
"create-jest-runner": "^0.6.0",
"dot-prop": "^5.3.0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This author is planning to make all their packages ESM-only - I’d strongly suggest avoiding adding them as a dependency.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went for v5 since v6 doesn't support node 8. We can migrate to some other module later if needed. Unless you have a good suggestion for a module that's not this or lodash? 😀

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a module for this? It always seems hacky to me to rely on converting a dotted string to object navigation; maybe there’s a different approach?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure - the ESLint class requires a bunch of stuff in configOverrides instead of in the root object, and deep merging is quite hellish in JS (without some module). Going with a dotted setter seemed like a nice shortcut for the specific CLI options we've added support for

(I'm not entirely sure why we have this normalization instead of passing through raw as-is, but that's a separate discussion)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll land this, and if we figure out some cleaner way of dealing with this we can revisit. It's not exposed, so it's an implementation detail we can change at will

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants