fix(eslint): eliminate IDE false positives in browser packages#6251
Merged
macko911 merged 2 commits intoMay 27, 2026
Merged
Conversation
The VS Code ESLint extension creates a separate TypeScript program for
every unique parserOptions.project value it encounters in matching config
blocks. Files in webapp/frontend/connect-ui matched both the root block
(project: './tsconfig.json', no DOM/React lib) and their own package
block, so type-aware rules ran with degraded types — every React hook
import became an error type, firing hundreds of spurious
no-unnecessary-type-assertion and unsafe-* violations in the IDE.
Fix:
- Extract shared tseslint preset list and custom rule overrides into
module-level variables (tseslintExtends, tseslintRules)
- Add ignores to the root **/*.{ts,tsx} block for the three browser
packages so the IDE never creates a root-tsconfig program for them
- Include the shared variables directly in each browser-package block
so they get the full rule set evaluated against their own tsconfig
No rules are added or removed; CI lint output is unchanged.
pfreixes
approved these changes
May 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Type-aware ESLint rules fire hundreds of false-positive errors in the IDE for
packages/webapp,packages/frontend, andpackages/connect-ui— but the same files pass lint cleanly in CI.The root cause: the VS Code ESLint extension creates a separate TypeScript program per unique
parserOptions.projectvalue it finds in matching config blocks. These browser-package files match both the root**/*.{ts,tsx}block (project: './tsconfig.json') and their own package block (project: 'packages/webapp/tsconfig.json'). The root tsconfig has no DOM or React lib, so the IDE type-checks React code against it, every hook import degrades to anerrortype, and rules likeno-unnecessary-type-assertionfire as false positives.The CLI doesn't have this problem because flat config merges all matching blocks into one before parsing — so only the last
parserOptions.projectwins and the correct tsconfig is used.Solution
Extracted the shared typescript-eslint presets and rule overrides into module-level variables (
tseslintExtends,tseslintRules), then:ignoresto the root**/*.{ts,tsx}block for the three browser packages — the IDE now creates only one TypeScript program (the package-specific one) for those files@typescript-eslintplugin +extends: tseslintExtends+rules: { ...tseslintRules }directly to each browser-package block so they get the full rule set evaluated against their own tsconfigNo rules were added or removed. CI lint output is unchanged.
Fixes NAN-5733
Testing
eslint packages/webapp/src/pages/Connection/CreateLegacy.tsx— same 8 warnings as before, no false positiveseslint packages/connect-ui/src/App.tsx+packages/frontend/lib/index.ts— no regressions