Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

feat(scope-manager): add ESLint 10 globals opt-in and guard#11832

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
michaelgiraldo wants to merge5 commits intotypescript-eslint:main
base:main
Choose a base branch
Loading
frommichaelgiraldo:fix/eslint10-addGlobals

Conversation

@michaelgiraldo
Copy link

@michaelgiraldomichaelgiraldo commentedDec 9, 2025•
edited
Loading

ESLint 10 changed how scope managers are supposed to work.

TypeScript-ESLint didn’t implement the new contract, which is why ESLint 10 crashes with the missingaddGlobals method.

This PR basically patches that gap:

  1. ImplementsscopeManager.addGlobals()
    This is the method ESLint 10 expects. Without it, ESLint blows up before running any rule.

  2. Adds a flag:resolveGlobalVarsInScript (default: false)
    ESLint 10 resolves globals differently in script mode.
    They didn’t want to break everyone on ESLint 8/9, so this flag gates the new behavior.

  3. Makes injected globals “value-only”
    Prevents accidental type-binding, which would hide legit TS errors.

  4. Adds cleanup logic for unresolved references
    ESLint 10 requires tidying up script-mode references; TS-ESLint wasn’t doing that.

That’s it. It’s compatibility plumbing.

ESLint 10 changed the rules of the game, and TypeScript-ESLint wasn’t playing by them.

This PR just makes the scope manager stop crashing and behave the way ESLint 10 expectswithout screwing over people still on older ESLint versions.

If you're upgrading to ESLint 10, this PR is the missing piece that unbreaks the world.

When you move to ESLint 10, turn this on:

{"parserOptions": {"resolveGlobalVarsInScript":true  }}

Otherwise script-mode globals won't resolve the way ESLint 10 expects.

🍊💾

@typescript-eslint
Copy link
Contributor

Thanks for the PR,@michaelgiraldo!

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 onhttps://opencollective.com/typescript-eslint.

@netlify
Copy link

netlifybot commentedDec 9, 2025•
edited
Loading

✅ Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commit7d9eba6
🔍 Latest deploy loghttps://app.netlify.com/projects/typescript-eslint/deploys/6937c0b14a931a000860deff
😎 Deploy Previewhttps://deploy-preview-11832--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: 96 (🔴 down 1 from production)
Accessibility: 97 (no change from production)
Best Practices: 100 (no change from production)
SEO: 92 (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 yourNetlify project configuration.

@nx-cloud
Copy link

nx-cloudbot commentedDec 9, 2025•
edited
Loading

View yourCI Pipeline Execution ↗ for commit7d9eba6

CommandStatusDurationResult
nx test eslint-plugin --coverage=false✅ Succeeded5m 11sView ↗
nx run-many -t lint✅ Succeeded3m 13sView ↗
nx run-many -t typecheck✅ Succeeded2m 12sView ↗
nx test eslint-plugin-internal --coverage=false✅ Succeeded10sView ↗
nx run integration-tests:test✅ Succeeded5sView ↗
nx run types:build✅ Succeeded2sView ↗
nx test typescript-estree --coverage=false✅ Succeeded1sView ↗
nx run generate-configs✅ Succeeded6sView ↗
Additional runs (29)✅ Succeeded...View ↗

☁️Nx Cloud last updated this comment at2025-12-09 06:37:50 UTC

@codecov
Copy link

codecovbot commentedDec 9, 2025•
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.55%. Comparing base (dd96947) to head (7d9eba6).

Additional details and impacted files
@@            Coverage Diff             @@##             main   #11832      +/-   ##==========================================+ Coverage   90.53%   90.55%   +0.01%==========================================  Files         523      523                Lines       53096    53162      +66       Branches     8838     8864      +26     ==========================================+ Hits        48073    48140      +67+ Misses       5010     5009       -1  Partials       13       13
FlagCoverage Δ
unittest90.55% <100.00%> (+0.01%)⬆️

Flags with carried forward coverage won't be shown.Click here to find out more.

Files with missing linesCoverage Δ
packages/scope-manager/src/ScopeManager.ts86.97% <100.00%> (+4.48%)⬆️
packages/scope-manager/src/analyze.ts100.00% <100.00%> (ø)
packages/scope-manager/src/scope/ScopeBase.ts95.93% <100.00%> (+0.01%)⬆️

... and1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@JoshuaKGoldberg
Copy link
Member

👋@michaelgiraldo thanks for the PR!

The description you've written isvery verbose. We have a very limited maintainer bandwidth and deeply reading through the whole thing would take up an unnecessarily large amount of time in it. We're working on docs in#11416 ->#11836. The tl;dr is: regardless of whether you use AI, excessively long descriptions actually harm understandability. Pithiness is good.

@bradzacher and I each took a cursory look at the code and there are a lot more changes than either of us expected for this feature. I'm not sure yet whether this is necessary, but given that the PR description seems to be AI-generated and not well human-reviewed, I don't think we want to spend our limited bandwidth reviewing a PR that might be AI-generated and not well human-reviewed.

I'm converting this to a draft for now. If you're still interested in this feature, please:

  • Reduce the PR description to something in line with what a human would normally write
  • Double-check the implementation to make sure it's something you can stand by

Feel free to re-request review & un-draft (you should have permissions to, ping me if not) once you've done those things.

Cheers!

kirkwaiblinger reacted with thumbs up emojimichaelgiraldo reacted with eyes emoji

@JoshuaKGoldbergJoshuaKGoldberg marked this pull request as draftDecember 10, 2025 17:02
@michaelgiraldo
Copy link
Author

michaelgiraldo commentedDec 10, 2025•
edited
Loading

@JoshuaKGoldberg is the write up is better? any other guidance, coding style, more tests? I want "stand by" my code with testing coverage.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@michaelgiraldo@JoshuaKGoldberg
[8]ページ先頭
©2009-2025 Movatter.jp