Skip to content

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

Merged
merged 39 commits into from
Jul 6, 2024

Conversation

abrahamguo
Copy link
Contributor

PR Checklist

Overview

Use eslint@9 internally.

@typescript-eslint
Copy link
Contributor

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.

Copy link

netlify bot commented May 18, 2024

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit 5ffa053
🔍 Latest deploy log https://app.netlify.com/sites/typescript-eslint/deploys/6682ae69ef7ba90008f21054
😎 Deploy Preview https://deploy-preview-9119--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 99 (🔴 down 1 from production)
Accessibility: 100 (no change from production)
Best Practices: 92 (no change from production)
SEO: 90 (no change from production)
PWA: 80 (no change from production)
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

@abrahamguo abrahamguo marked this pull request as draft May 18, 2024 22:41
@abrahamguo abrahamguo marked this pull request as ready for review May 22, 2024 01:50
@bradzacher
Copy link
Member

bradzacher commented May 22, 2024

We should delete this CI job

eslint_v9_tests:
name: Run tests on ESLint v9
needs: [build]
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Install
uses: ./.github/actions/prepare-install
with:
node-version: ${{ env.PRIMARY_NODE_VERSION }}
- name: Build
uses: ./.github/actions/prepare-build
- run: yarn add eslint@9
- name: Run tests
run: yarn test
env:
CI: true

have we got an existing integration test to check for regressions on eslint v8?


converting to draft until CI is passing.

@bradzacher bradzacher marked this pull request as draft May 22, 2024 11:48
@bradzacher bradzacher added this to the 8.0.0 milestone May 22, 2024
@abrahamguo
Copy link
Contributor Author

@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

@bradzacher
Copy link
Member

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
So nothing to add!

Also, seems unrelated to this PR since this is about using eslint 9 internally

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.
It's not a super exhaustive test but it'll do (it's the same integration test coverage we maintained when we migrated to v8 internally)

@mattbrannon
Copy link

Just wanted to point out that one of your Netlify jobs has been running for nearly a week.
https://github.com/typescript-eslint/typescript-eslint/pull/9119/checks?check_run_id=25428243220

['eslint-comments']: eslintCommentsPlugin,
['eslint-plugin']: eslintPluginPlugin,
['import']: importPlugin,
// https://github.com/import-js/eslint-plugin-import/issues/2948
['import']: fixupPluginRules(importPlugin),
Copy link
Member

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?

Copy link
Member

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.

Comment on lines +520 to +521
...fixupConfigRules(compat.config(reactPlugin.configs.recommended)),
...fixupConfigRules(compat.config(reactHooksPlugin.configs.recommended)),
Copy link
Member

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

Copy link
Contributor Author

@abrahamguo abrahamguo Jun 27, 2024

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.

@JoshuaKGoldberg JoshuaKGoldberg changed the title feat: use eslint 9 internally chore: use eslint 9 internally Jun 26, 2024
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a 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 */
Copy link
Member

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...

@JoshuaKGoldberg JoshuaKGoldberg added the awaiting response Issues waiting for a reply from the OP or another party label Jun 26, 2024
@github-actions github-actions bot removed the awaiting response Issues waiting for a reply from the OP or another party label Jun 28, 2024
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

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

Whoohoo! Thanks!! 🚀

@JoshuaKGoldberg JoshuaKGoldberg added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Jun 29, 2024
@abrahamguo
Copy link
Contributor Author

abrahamguo commented Jul 1, 2024

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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!

Copy link
Member

@auvred auvred left a comment

Choose a reason for hiding this comment

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

🚀

@JoshuaKGoldberg JoshuaKGoldberg merged commit 86811d7 into typescript-eslint:v8 Jul 6, 2024
61 of 62 checks passed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants