Skip to content
This repository has been archived by the owner on Feb 18, 2024. It is now read-only.

ESLint 6.0.0 compatibility #1423

Closed
edclement opened this issue Jun 24, 2019 · 7 comments
Closed

ESLint 6.0.0 compatibility #1423

edclement opened this issue Jun 24, 2019 · 7 comments
Assignees
@edmorley
Labels
breaking change feature
Milestone
Neutrino 9

Comments

@edclement
Copy link

Bug or issue?

Please try to answer the following questions:

  • What version of Neutrino are you using? 9.0.0-rc3
  • Are you trying to use any presets? If so, which ones, and what versions?
    • "@neutrinojs/copy": "9.0.0-rc.3"
    • "@neutrinojs/jest": "9.0.0-rc.3"
    • "@neutrinojs/react": "9.0.0-rc.3"
    • "@neutrinojs/standardjs": "9.0.0-rc.3"
  • Are you using the Yarn client or the npm client? What version?
  • What version of Node.js are you using? 10.16.0
  • What operating system are you using? Ubuntu 18.04.2 LTS
  • What did you do? Update ESLint to 6.0.0
  • What did you expect to happen? Linting to work
  • What actually happened, contrary to your expectations?
# npm run lint

> lint /home/<REDACTED>/Git/<REDACTED>/<REDACTED>
> eslint --format codeframe --ext js ./src ./e2e ./*.js .neutrinorc.js

Error: Cannot read config file: /home/<REDACTED>/Git/<REDACTED>/<REDACTED>/.eslintrc.js
Error: Cannot find module 'eslint/lib/config/config-ops'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:690:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/home/<REDACTED>/Git/<REDACTED>/<REDACTED>/node_modules/@neutrinojs/eslint/index.js:2:32)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! <REDACTED>@0.1.0 lint: `eslint --format codeframe --ext js ./src ./e2e ./*.js .neutrinorc.js`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the <REDACTED>@0.1.0 lint script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/<REDACTED>/.npm/_logs/2019-06-24T13_58_59_802Z-debug.log
@edclement
Copy link
Author

Link to their migration guide: https://eslint.org/docs/user-guide/migrating-to-6.0.0

@edclement
Copy link
Author

edclement commented Jun 24, 2019 •
edited
Loading

Did some digging, looks like they just moved the location: https://github.com/eslint/eslint/blob/v6.0.0/lib/shared/config-ops.js

@edmorley
Copy link
Member

Hi! Thank you for opening an issue. Adding support for ESLint 6 is on our list of things to do, however it's blocked on a few pre-requisites first (eg support in the AirBnB preset and plugins), along with some changes on our side. Some initial discussion has occurred in #1421 :-)

@helfi92 helfi92 mentioned this issue Jun 25, 2019
Closed
1 task
@djmitche
Copy link

djmitche commented Sep 5, 2019

Eslint 5 currently has a few dependencies with active sec vulns. It'd be really nice to not be stuck on such an ancient version.

@edmorley
Copy link
Member

edmorley commented Sep 5, 2019 •
edited
Loading

Hi! ESLint 5 isn't vulnerable itself, one of its transitive dependencies can be, if not updated via the lockfile. ESLint 6 bumping its deps to force users onto the newer version (thereby not relying on them knowing to refresh the lockfile) is definitely a win - though more the icing on the cake:
https://eslint.org/blog/2019/08/eslint-v6.2.1-released

For what it's worth, I'd love to upgrade to ESLint 6, it's just non-trivial given #1421 (comment) - and I no longer work on JS for my day job so don't get a huge amount of time to spend on Neutrino. I'd also point out that v6.2.1 (that contains the dep bump to force the security fix) was only released 20th Aug, and ESLint 6 itself only June (and it's never possible to upgrade immediately given preset ecosystem), so "ancient" is perhaps a little bit of an overstatement :-)

@djmitche
Copy link

djmitche commented Sep 5, 2019

Sorry about "ancient" - I was referring to v5, rather than 6.2.1.

@edmorley edmorley mentioned this issue Sep 9, 2019
Merged
@edmorley
Copy link
Member

edmorley commented Sep 9, 2019

I've opened #1464 to remove the usages of ESLint internal APIs that were blocking the ESLint 6 upgrade in #1421. If anyone has a spare moment to review, it will help speed up progress :-)

edmorley added a commit that referenced this issue Sep 9, 2019
@edmorley
Stop using private ESLint APIs for ESLint config merging (#1464)
79d4eda 
In #1182, the previous broken ESLint config merging functionality was
replaced by using an internal ESLint `merge` function from `config-ops`.

Unfortunately in ESLint 6 that function no longer exists in a form that
is easy for us to use, so in order to support ESLint 6, I have replaced
it with simpler manual merges. These are virtually identical, with one
difference - `rules` are now merged by a later rule entry completely
replacing the first, rather than updating it.

For example, merging these:
`'foo': ['error', {'someSetting': false}]`
`'foo': 'warn'`

...used to give:
`'foo': ['warn', {'someSetting': false}]`

...but now results in:
`'foo': 'warn'`

I think this difference is a reasonable compromise for not having to
rely on ESLint internals and/or implement our own more complex merging.
I also believe hitting this will be rare, since:
* it doesn't affect merging with rules defined inside an `extends`
  external file
* it won't make a difference for rules that were already at default
  settings (or that were overridden with custom settings in the later
  rule definition being merged in)

This more simplistic merging behaviour is also what's used by Neutrino 8
(#1182 landed for Neutrino 9 only) - and we still have the other bug
fixes included in #1182 that were the primary motivation for refactoring
in the first place.

Refs #1423.
@edmorley edmorley added this to the Neutrino 9 milestone Sep 9, 2019
@edmorley edmorley self-assigned this Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@edmorley edmorley

Labels
breaking change feature
Milestone
Neutrino 9
Development

No branches or pull requests
3 participants
@djmitche @edmorley @edclement