-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
chore: use eslint 9 internally #9119
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
Conversation
Thanks for the PR, @abrahamguo! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
We should delete this CI job typescript-eslint/.github/workflows/ci.yml Lines 137 to 154 in 87a0a48
have we got an existing integration test to check for regressions on eslint v8? converting to draft until CI is passing. |
@bradzacher there are currently no integration or CI tests for eslint 8. I can add one if you want, but do you feel that's necessary since we ask for eslint 9 in both our peerDependencies and devDependencies? Doesn't seem like anything similar was added for eslint 7 when we moved from eslint 7=>8 (#3737) Also, seems unrelated to this PR since this is about using eslint 9 internally |
Looks like there's already an integration test for v8 - https://github.com/typescript-eslint/typescript-eslint/tree/main/packages/integration-tests/fixtures/eslint-v8
By moving to v9 internally our CI is no longer running against v8 - so we lose the test coverage asserting that we don't regress v8 compat. But given we have the above integration test - we still have enough coverage. |
Just wanted to point out that one of your Netlify jobs has been running for nearly a week. |
['eslint-comments']: eslintCommentsPlugin, | ||
['eslint-plugin']: eslintPluginPlugin, | ||
['import']: importPlugin, | ||
// https://github.com/import-js/eslint-plugin-import/issues/2948 | ||
['import']: fixupPluginRules(importPlugin), |
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.
we might want to consider switching to eslint-plugin-import-x
?
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.
I'd be in support of this as a separate followup yeah.
...fixupConfigRules(compat.config(reactPlugin.configs.recommended)), | ||
...fixupConfigRules(compat.config(reactHooksPlugin.configs.recommended)), |
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.
it's so weird that we need to fixup the plugin both here and in the plugin def.
seems like quite the flaw in the design of the compat tooling tbh
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.
@bradzacher that's actually not true.
This can be removed if you are OK with me editing the section at the top of this file labeled registering all the plugins up-front
, and removing any plugin for which we use a shared config (for example, reactPlugin
and reactHooksPlugin
).
Shared configs automatically register their corresponding plugin, so it is unnecessary to manually register the plugin.
The flip side, of course, would be if you felt that it's important to preserve a complete up-front list of all plugins used in any part of the config.
If we choose to keep the complete up-front list of plugins, then the reason why we have to use the compat utilities twice, is because the plugins are defined twice (again, redundantly so), and we need to make sure that in both places that each plugin is registered, it is the fixed-up version.
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.
I think we'll need to keep ESLint 8 testing in there for a while - and there is some noise making it harder to review. But encouraging as a start! 🌞
@@ -1,4 +1,3 @@ | |||
/* eslint-disable @typescript-eslint/no-unsafe-assignment */ |
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.
[Non-Actionable] Heh, I wonder how much this will come into conflict with #9339...
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.
Whoohoo! Thanks!! 🚀
ESLint 9 displays unused lint suppressions as warnings, not errors (different from ESLint 8, which did not report unused lint suppressions), so there were 3 unused lint suppressions that were displayed in the pipeline but did not block it. I've removed all of those, and provided an explanation for each one. |
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.
ESLint 9 displays unused lint suppressions as warnings, not errors, so there were 3 unused lint suppressions that were displayed in the pipeline but did not block it. I've removed all of those, and provided an explanation for each one.
Hmmm, turns out our eslint.config.mjs
doesn't have linterOptions: { reportUnusedDisableDirectives: 'error' }
. Maybe this is a good chance to turn it on?
This seems a bit suspicious to me though: this option has not been enabled for this repository until now. Maybe there are some considerations in favor of leaving this option disabled?
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.
Just want to clarify that it was the upgrade from ESLint 8 to ESLint 9 that caused it to begin reporting unnecessary lint suppressions.
I feel like it makes sense to keep it at the default value, or change the level from warning
to error
, but I'm open to further discussion.
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.
Yeah I'd +1 switching to error
as a followup. Great find!
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.
🚀
PR Checklist
Overview
Use eslint@9 internally.