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

fix(scope-manager): reconcile type-value distinction for implicit globals across libs#11715

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

Closed
lilnasy wants to merge2 commits intotypescript-eslint:mainfromlilnasy:main

Conversation

@lilnasy
Copy link

PR Checklist

Overview

To fix the issue, implicit variables are mutated as the global scope is being populated.

I admittedly did not spend much time thinking of a proper solution. Though it was tricky to pinpoint, the fix is simple. I imagine the "correct" location for the fix is a matter of maintainer preference.

Direct commits from maintainers welcome.

@typescript-eslint
Copy link
Contributor

Thanks for the PR,@lilnasy!

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 commentedOct 23, 2025
edited
Loading

Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commit381f374
🔍 Latest deploy loghttps://app.netlify.com/projects/typescript-eslint/deploys/691cc5cb2055780008dd5de6
😎 Deploy Previewhttps://deploy-preview-11715--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 (🟢 up 2 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.

@lilnasylilnasy changed the titlefix(scope manager): reconcile type-value distinction for implicit globals across libsfix(scope-manager): reconcile type-value distinction for implicit globals across libsOct 23, 2025
@nx-cloud
Copy link

nx-cloudbot commentedOct 23, 2025
edited
Loading

🤖 Nx Cloud AI Fix Eligible

An automatically generated fix could have helped fix failing tasks for this run, but Self-healing CI is disabled for this workspace. Visit workspace settings to enable it and get automatic fixes in future runs.

To disable these notifications, a workspace admin can disable themin workspace settings.


View yourCI Pipeline Execution ↗ for commit381f374

CommandStatusDurationResult
nx run-many -t lint❌ Failed3m 21sView ↗
nx test eslint-plugin --coverage=false✅ Succeeded5m 23sView ↗
nx run-many -t typecheck✅ Succeeded1m 59sView ↗
nx test eslint-plugin-internal --coverage=false✅ Succeeded12sView ↗
nx test typescript-estree --coverage=false✅ Succeeded2sView ↗
nx run integration-tests:test✅ Succeeded4sView ↗
nx run types:build✅ Succeeded5sView ↗
nx run generate-configs✅ Succeeded7sView ↗
Additional runs (29)✅ Succeeded...View ↗

☁️Nx Cloud last updated this comment at2025-11-18 19:27:48 UTC

@codecov
Copy link

codecovbot commentedOct 23, 2025
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.55%. Comparing base (28cf803) to head (381f374).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@##             main   #11715   +/-   ##=======================================  Coverage   90.55%   90.55%           =======================================  Files         522      522             Lines       53063    53073   +10       Branches     8838     8842    +4     =======================================+ Hits        48049    48059   +10- Misses       4999     5000    +1+ Partials       15       14    -1
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/scope/ScopeBase.ts96.04% <100.00%> (+0.12%)⬆️
.../scope-manager/src/variable/ImplicitLibVariable.ts87.50% <100.00%> (ø)
🚀 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.

Copy link
Member

@bradzacherbradzacher left a comment

Choose a reason for hiding this comment

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

instead of mutating the variable here -- could we instead do it higher.

eg:

In theGlobalScope class (which callsScopeBase.defineVariable):

publicdefineImplicitVariable(
name:string,
options:ImplicitLibVariableOptions,
):void{
this.defineVariable(
newImplicitLibVariable(this,name,options),
this.set,
this.variables,
null,
null,
);
}

Or in theReferencer class (which callsGlobalScope.defineImplicitVariable):

// This loop is guaranteed to see each included lib exactly once
for(const[name,variable]oflib.variables){
globalScope.defineImplicitVariable(name,variable);
}

I think the latter would be better as we could pre-aggregate the variable definitions to deduplicate and merge them before even callingdefineImplicitVariable.

@lilnasy
Copy link
Author

@bradzacher I'm thinking it would be even better to go one level higher.

The first year-wise occurrence of the globals I glimpsed at seems to always beTYPE_VALUE. If that holds true for all, we could simply ensure the iteration is in chronological order at runtime and it would work. The test could be made more comprehensive to prevent regressions.

@lilnasy
Copy link
Author

lilnasy commentedNov 10, 2025
edited
Loading

I have a branch where Iflatten the lib references at codegen time instead of at runtime, fixing the bug right there. It increases the package size a little but reducesScopeManager instantiation time.

I can move forward with whichever approach maintainers prefer.

overlookmotel pushed a commit to oxc-project/oxc that referenced this pull requestNov 17, 2025
- Part of#14827- Fixes the bug noticed in a review in#14890 (comment)- Originally reported astypescript-eslint/typescript-eslint#11714- Originally fixed intypescript-eslint/typescript-eslint#11715- Patching in oxlint because neither the bug nor the fix has beenreviewed in the `typescript-eslint` org.
@bradzacher
Copy link
Member

I believe the behaviour that we will need to add as part of the eslint v10 upgrades will provide you the behaviour you want.

This behaviour will resolve all references to globals as part of the analysis rather than leaving them all open.

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commentedNov 28, 2025
edited
Loading

@bradzacher so just confirming, is there any change we should make here? Is#11714 a no-op/wontfix given the upcoming ESLint v10 changes?

Linking for visibility:#11762 tracks updating scope-manager for compatibility with ESLint v10.

@JoshuaKGoldbergJoshuaKGoldberg added the triageWaiting for team members to take a look labelNov 28, 2025
@lilnasy
Copy link
Author

I believe the behaviour that we will need to add as part of the eslint v10 upgrades will provide you the behaviour you want.

I agree.

Is#11714 a no-op/wontfix given the upcoming ESLint v10 changes?

@JoshuaKGoldberg I think that depends on what you meant in the comment here:#11762 (comment). Could you clarify? Can@typescript-eslint/scope-manager remain compatible with both ESLint v8 and v10?

@JoshuaKGoldberg
Copy link
Member

We haven't looked deeply into it yet, but I really hope so. Dropping support for v8 and v9 would be a breaking change that we're not ready to release a new major version for anytime soon.

@bradzacher
Copy link
Member

Well technically by being compatible with v10 we're also compatible with v8/v9 - cos eslint will just have nothing to do.

@lilnasy
Copy link
Author

Thanks, I thought that might be the case. Fixing this as part of ESLint 10 compat seems appropriate. Oxlint will be able to remove the patch we made to@typescript-eslint/scope-manager then (if it happens before our rust reimplementation).

bradzacher reacted with thumbs up emoji

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

Reviewers

@bradzacherbradzacherAwaiting requested review from bradzacher

Assignees

No one assigned

Labels

triageWaiting for team members to take a look

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Scope Manager fails to pick up references to implicit globals

3 participants

@lilnasy@bradzacher@JoshuaKGoldberg

[8]ページ先頭

©2009-2025 Movatter.jp