-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[New] support eslint 9 #2996
[New] support eslint 9 #2996
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2996 +/- ##
==========================================
- Coverage 95.20% 95.07% -0.14%
==========================================
Files 82 82
Lines 3565 3571 +6
Branches 1245 1251 +6
==========================================
+ Hits 3394 3395 +1
- Misses 171 176 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
7c59670
to
543e378
Compare
This comment was marked as outdated.
This comment was marked as outdated.
I've just gotten back from travel, so I'll try to take a look at it in the coming days. One likely obstacle is that all the tests assume eslintrc, but eslint 9 requires an env var to support it, otherwise it defaults to flat config. The initial support needs to test eslintrc, and it would be fine to add flat config tests in a follow-on if needed. It's likely that the way eslint < 9's RuleTester works is subtly different than in eslint 9, so we may need an abstraction to handle that. |
Yup part of this includes switching to a custom rule tester that converts the tests from eslintrc to flat config if they're running on v9, which is what we've been using in |
That's great, but testing eslintrc on eslint 9 is also very important. It'd also be great if there was a commit or two I could land separately, that worked on eslint < 9, so that only the 9-specific parts remained in this PR after that was landed and rebased :-) |
If you're meaning the context helper stuff, yeah I'm happy to pull them out I just figured you'd have asked them to be tested against ESLint v9 to prove they actually worked :-) |
You figured right :-) but i can just cherry-pick the commits out of this PR once things are working. |
Right well they're already good for cherry-picking - you want to pick from e31fe5c...543e378 (sans f0853cb once #2997 is landed), and away you go. I think you can have the eslintrc-on-v9 support by just running the whole test suite twice with the env enabled and an extra test in the custom rule tester - I'll push that up shortly |
@ljharb |
well that sucks, we’ll need to file an eslint issue about that gap. |
I'll leave that to you as I suspect you'll have more pull :-) |
Filed eslint/eslint#18292. |
7d42925
to
f3318fb
Compare
5429dab
to
f1e7cd2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help me understand what withoutAutofixOutput
is for?
This comment was marked as outdated.
This comment was marked as outdated.
Totally, while it's still a draft I'm indeed just chipping away at the review :-) your effort is appreciated! |
| datasource | package | from | to | | ---------- | -------------------- | ------ | ------ | | npm | eslint-plugin-import | 2.30.0 | 2.31.0 | ## [v2.31.0](https://github.com/import-js/eslint-plugin-import/blob/HEAD/CHANGELOG.md#2310---2024-10-03) ##### Added - support eslint v9 (\[[#2996](import-js/eslint-plugin-import#2996)], thanks \[[@G-Rath](https://github.com/G-Rath)] \[[@michaelfaith](https://github.com/michaelfaith)]) - \[`order`]: allow validating named imports (\[[#3043](import-js/eslint-plugin-import#3043)], thanks \[[@manuth](https://github.com/manuth)]) - \[`extensions`]: add the `checkTypeImports` option (\[[#2817](import-js/eslint-plugin-import#2817)], thanks \[[@phryneas](https://github.com/phryneas)]) ##### Fixed - `ExportMap` / flat config: include `languageOptions` in context (\[[#3052](import-js/eslint-plugin-import#3052)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - \[`no-named-as-default`]: Allow using an identifier if the export is both a named and a default export (\[[#3032](import-js/eslint-plugin-import#3032)], thanks \[[@akwodkiewicz](https://github.com/akwodkiewicz)]) - \[`export`]: False positive for exported overloaded functions in TS (\[[#3065](import-js/eslint-plugin-import#3065)], thanks \[[@liuxingbaoyu](https://github.com/liuxingbaoyu)]) - `exportMap`: export map cache is tainted by unreliable parse results (\[[#3062](import-js/eslint-plugin-import#3062)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - `exportMap`: improve cacheKey when using flat config (\[[#3072](import-js/eslint-plugin-import#3072)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - adjust "is source type module" checks for flat config (\[[#2996](import-js/eslint-plugin-import#2996)], thanks \[[@G-Rath](https://github.com/G-Rath)]) ##### Changed - \[Docs] \[`no-relative-packages`]: fix typo (\[[#3066](import-js/eslint-plugin-import#3066)], thanks \[[@joshuaobrien](https://github.com/joshuaobrien)]) - \[Performance] \[`no-cycle`]: dont scc for each linted file (\[[#3068](import-js/eslint-plugin-import#3068)], thanks \[[@soryy708](https://github.com/soryy708)]) - \[Docs] \[`no-cycle`]: add `disableScc` to docs (\[[#3070](import-js/eslint-plugin-import#3070)], thanks \[[@soryy708](https://github.com/soryy708)]) - \[Tests] use re-exported `RuleTester` (\[[#3071](import-js/eslint-plugin-import#3071)], thanks \[[@G-Rath](https://github.com/G-Rath)]) - \[Docs] \[`no-restricted-paths`]: fix grammar (\[[#3073](import-js/eslint-plugin-import#3073)], thanks \[[@unbeauvoyage](https://github.com/unbeauvoyage)]) - \[Tests] \[`no-default-export`], \[`no-named-export`]: add test case (thanks \[[@G-Rath](https://github.com/G-Rath)])
| datasource | package | from | to | | ---------- | -------------------- | ------ | ------ | | npm | eslint-plugin-import | 2.30.0 | 2.31.0 | ## [v2.31.0](https://github.com/import-js/eslint-plugin-import/blob/HEAD/CHANGELOG.md#2310---2024-10-03) ##### Added - support eslint v9 (\[[#2996](import-js/eslint-plugin-import#2996)], thanks \[[@G-Rath](https://github.com/G-Rath)] \[[@michaelfaith](https://github.com/michaelfaith)]) - \[`order`]: allow validating named imports (\[[#3043](import-js/eslint-plugin-import#3043)], thanks \[[@manuth](https://github.com/manuth)]) - \[`extensions`]: add the `checkTypeImports` option (\[[#2817](import-js/eslint-plugin-import#2817)], thanks \[[@phryneas](https://github.com/phryneas)]) ##### Fixed - `ExportMap` / flat config: include `languageOptions` in context (\[[#3052](import-js/eslint-plugin-import#3052)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - \[`no-named-as-default`]: Allow using an identifier if the export is both a named and a default export (\[[#3032](import-js/eslint-plugin-import#3032)], thanks \[[@akwodkiewicz](https://github.com/akwodkiewicz)]) - \[`export`]: False positive for exported overloaded functions in TS (\[[#3065](import-js/eslint-plugin-import#3065)], thanks \[[@liuxingbaoyu](https://github.com/liuxingbaoyu)]) - `exportMap`: export map cache is tainted by unreliable parse results (\[[#3062](import-js/eslint-plugin-import#3062)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - `exportMap`: improve cacheKey when using flat config (\[[#3072](import-js/eslint-plugin-import#3072)], thanks \[[@michaelfaith](https://github.com/michaelfaith)]) - adjust "is source type module" checks for flat config (\[[#2996](import-js/eslint-plugin-import#2996)], thanks \[[@G-Rath](https://github.com/G-Rath)]) ##### Changed - \[Docs] \[`no-relative-packages`]: fix typo (\[[#3066](import-js/eslint-plugin-import#3066)], thanks \[[@joshuaobrien](https://github.com/joshuaobrien)]) - \[Performance] \[`no-cycle`]: dont scc for each linted file (\[[#3068](import-js/eslint-plugin-import#3068)], thanks \[[@soryy708](https://github.com/soryy708)]) - \[Docs] \[`no-cycle`]: add `disableScc` to docs (\[[#3070](import-js/eslint-plugin-import#3070)], thanks \[[@soryy708](https://github.com/soryy708)]) - \[Tests] use re-exported `RuleTester` (\[[#3071](import-js/eslint-plugin-import#3071)], thanks \[[@G-Rath](https://github.com/G-Rath)]) - \[Docs] \[`no-restricted-paths`]: fix grammar (\[[#3073](import-js/eslint-plugin-import#3073)], thanks \[[@unbeauvoyage](https://github.com/unbeauvoyage)]) - \[Tests] \[`no-default-export`], \[`no-named-export`]: add test case (thanks \[[@G-Rath](https://github.com/G-Rath)])
I'm getting error:
Update: nevermind. Looks like in my case some another plugin re-use same plugin |
Do not define the plugin |
eslint-plugin-import was missing since the switch to [v9](#3558). They finally [support](import-js/eslint-plugin-import#2996) it so we can re-add it.
> [!WARNING] > **Breaking Change:** Now uses `eslint-plugin-react-hooks@5.0.0` which has a new violation disallowing Component names starting with anything but an uppercase letter. See https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0 for more details. Adds support of ESLint v9 to `eslint-plugin-next`, `eslint-config-next` and `next lint`. Does not require using the new flat config format. `next lint` will automatically ensure the old config format can be used. ### Why? As `eslint-plugin-react-hooks` has been updated for ESLint v9 support and is a helpful package for Next v15 upgrade, unblock the restrictions to upgrade to ESLint v9. Also, ESLint v8 is [End of Life](https://eslint.org/blog/2024/09/eslint-v8-eol-version-support/#:~:text=ESLint%20v8.-,x%20end%20of%20life%20is%20October%205%2C%202024,x%20on%20October%205%2C%202024.) support since Oct 5th, so is good to unblock v9 now. Plugins bumped: - [x] [@rushstack/eslint-patch](microsoft/rushstack#4719) ([v1.10.3](https://www.npmjs.com/package/@rushstack/eslint-patch/v/1.10.3?activeTab=versions) no release post, confirmed on NPM) - [x] [@typescript-eslint/eslint-plugin](typescript-eslint/typescript-eslint#9002) ([v8.0.0](typescript-eslint/typescript-eslint#9002 (comment))) - [x] [eslint-plugin-import](import-js/eslint-plugin-import#2996) ([v2.31.0](https://github.com/import-js/eslint-plugin-import/releases/tag/v2.31.0)) - [x] [eslint-plugin-jsx-a11y](jsx-eslint/eslint-plugin-jsx-a11y#1009) ([v6.10.0](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/releases/tag/v6.10.0)) - [x] [eslint-plugin-react](jsx-eslint/eslint-plugin-react#3759) ([v7.35.0](https://github.com/jsx-eslint/eslint-plugin-react/releases/tag/v7.35.0)) - [x] [eslint-plugin-react-hooks](facebook/react#28773) ([v5.0.0](https://github.com/facebook/react/releases/tag/eslint-plugin-react-hooks%405.0.0)) We have to switch to ESLint v9 in our repo due to a pnpm bug where it automatically uses ESLint v9 even though we only installed it via `eslint-v9: npm:eslint@9.0.0`. This is a pnpm bug that wouldn't happen with Yarn v1, v4 nor NPM. Closes #64409 Closes #64114 Closes #64453 Closes NEXT-3293 --------- Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
This change adds helper functions to `eslint-module-utils` in order to add eslint v9 support to `eslint-plugin-import` in a backwards compatible way. Contributes to import-js#2996
This reduces the diff in import-js#2996.
Discovered this issue in import-js#2996 (comment) This change improves the logic for generating the cache key used for both the exportMap cache and resolver cache when using flat config. Prior to this change, the cache key was a combination of the `parserPath`, a hash of the `parserOptions`, a hash of the plugin settings, and the path of the file. When using flat config, `parserPath` isn't provided. So, there's the possibility of incorrect cache objects being used if someone ran with this plugin using different parsers within the same lint execution, if parserOptions and settings are the same. The equivalent cacheKey construction when using flat config is to use `languageOptions` as a component of the key, rather than `parserPath` and `parserOptions`. One caveat is that the `parser` property of `languageOptions` is an object that oftentimes has the same two functions (`parse` and `parseForESLint`). This won't be reliably distinct when using the base JSON.stringify function to detect changes. So, this implementation uses a replace function along with `JSON.stringify` to stringify function properties along with other property types. To ensure that this will work properly with v9, I also tested this against import-js#2996 with v9 installed. Not only does it pass all tests in that branch, but it also removes the need to add this exception: import-js#2996 (comment)
Resolves #2948