[Fix] correct flatConfigs types so flat-config usage type-checks - #3271
[Fix] correct flatConfigs types so flat-config usage type-checks#3271KAMRONBEK wants to merge 1 commit into
flatConfigs types so flat-config usage type-checks#3271Conversation
…pe tests The root index.d.ts declared `flatConfigs['stage-0']`, but the runtime `flatConfigs` object in src/index.js has no `stage-0` key, so the types promised a defined flat config that is `undefined` at runtime. Also adds a type-test suite (wired into `test-types`) locking in that `flatConfigs`/`configs` and their entries are non-optional, fully-typed `Linter.FlatConfig`/`Linter.LegacyConfig` values, matching the README flat-config examples. Fixes import-js#3169.
|
@ljharb TL;DR for #3169: the shipped root |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3271 +/- ##
=======================================
Coverage 79.58% 79.58%
=======================================
Files 98 98
Lines 4527 4527
Branches 1529 1529
=======================================
Hits 3603 3603
Misses 924 924 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
5742346 to
d49e0c1
Compare
d49e0c1 to
7fd75c2
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Problem
#3169 reports that following the README's TypeScript flat-config example yields
'importPlugin.flatConfigs' is possibly 'undefined'andany-typed configs.Root cause / investigation
The issue was filed 2025-03-22, when the latest release was v2.31.0 — which shipped no types at all (the
index.d.tsadded in #3097 first shipped in v2.32.0). That explains the reported errors and the reporter'sdeclare module 'eslint-plugin-import'workaround (an ambient override only takes effect when the package ships no declarations).I verified the shipped 2.32.0
index.d.tsagainst the current ecosystem: both README flat-config examples (export default [...]andtseslint.config(...)), plusdefineConfig(...)andplugins: { import: importPlugin }usage, type-check cleanly withtsc --strict(skipLibCheck: false) against eslint 9.39.5 and 10.7.0, TypeScript 5.9.3 and 7.0.2, so the originally-reported errors are already resolved onmain.One genuine mismatch remains:
index.d.tsdeclaresflatConfigs['stage-0'], but the runtimeflatConfigsobject insrc/index.jshas nostage-0key (it exists only in the legacyconfigs). TypeScript reports a definedLinter.FlatConfigfor a value that isundefinedat runtime, so spreading it into a config crashes despite a clean type-check.Fix
'stage-0'from theflatConfigsdeclaration inindex.d.ts(legacyconfigs['stage-0']is kept — it exists at runtime).tests/types/(compiled bynpm run test-typesalongside the existing bareindex.d.tscheck) asserting:flatConfigs/configsand every entry are non-optional and notany; every flat config is assignable toLinter.FlatConfigand every legacy config toLinter.LegacyConfig; the plugin object is assignable toESLint.Plugin; andflatConfigs['stage-0']stays a type error (@ts-expect-error).Tests
tsc -p tests/typespasses with the fix and fails (TS2578 unused@ts-expect-error) with thestage-0removal reverted — verified under both TypeScript 5.9.3 and 7.0.2 (the latter matching CI'stypescript@latest). The tests/types tsconfig avoids options removed in TS 7 (baseUrl,moduleResolution: node10), sotest-typeskeeps working as CI'stypescript@latestadvances.Independence from #3213
#3213 changes runtime exports in
src/index.js(default-export identity /meta) and does not touchindex.d.ts; its new package test explicitly expectsstage-0to be absent from flat configs, consistent with this change. The two merge cleanly in either order.Fixes #3169.