Repository navigation
Having noImplicitAny Not Enabled Impacts Type Inference #47294
Description
Activity
For anyone else checking, it has nothing to do with the initializer.
Playground link with
noImplicitAnydisabledfunction foo1(fnArray1: Array<string | number>) { // `item` and `key` are both typed as expected (`string | number` and `number`) const mapped1 = fnArray1.map((item, key) => [item, key]) } function foo2(fnArray2: Array<string> | Array<number>) { // `item` and `key` are both typed as `any` const mapped2 = fnArray2.map((item, key) => [item, key]) }
This is apparently by design. See #42620. I presume code existed before that PR that depends on parameters being assigned type
anywhen-noImplicitAnyis disabled.Reacted by Daniel RosenwasserThanks for digging that up, totally forgot about it!
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
- locked as resolved and limited conversation to collaborators
on Oct 22, 2025
Bug Report
🔎 Search Terms
array union types type inference noImplicitAny disabled
🕗 Version & Regression Information
This changed between versions
4.2.3and4.3.5, as before4.3.5, type inference for the 2nd case inferredanyregardless of ifnoImplicitAnywas enabled. After4.3.5, the expected inference happens whennoImplicitAnyis enabled, but behaves as it did before4.3.5whennoImplicitAnyis not enabled.⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
When
noImplicitAnyis not enabled in the TS config, inferred types are impacted (inferred asanyin the above case).🙂 Expected behavior
noImplicitAnyshouldn't impact inferred types, or if this is expected behaviour as having this option enabled allows for better heuristics to work, then I think having it documented that this settings isn't essentially just a "lint rule" might be a good idea.