Repository navigation
[5.4 regression] Conditional type changes behavior with 5.4-beta #57221
Description
Activity
Andarist commented
on Jan 29, 2024 ContributorMore actionsbisected to #56515
Andarist commented
on Jan 29, 2024 ContributorMore actionsI can confirm that
inferToMappedTypeis now able to infer more because theconstraintTypethat it receives is a type parameter (T) and not an intersection like before (T & string). The mentioned intersection was reduced to justTas per #56515 so I think this is working as intended.The
NoInferlooks like a good workaround to this issue because that's precisely what it is useful for - it limits the inference sources and #56515 made the second argument a viable inference source here.I feel like this is the same problem that breaks the inference in MikroORM for the populate hints (and many other things that work on the same basis), it starts to break with
5.4.0-dev.20231121, previously I was able to infer string literals and now I only getstringwhich breaks other types. I'll try to work on a playground when I have some spare time and open a separate issue, but the types are pretty complex so it might take some time.If this is considered WAI, I am honestly scared... 🤣 The use case on our end is more complex than just validation, we need inference so the types can be used in the return values.
Will work on the repro and open a new issue soon'ish, just wanted to bring this up, as I feel a storm is coming (already got a report about this some time ago).
edit: solved via mikro-orm/mikro-orm#5197
RyanCavanaugh commented
on Feb 1, 2024 MemberMore actionsThe difference here is in the type parameter inference. In 5.4 we get
"foo" | "/:foo/:bar/"whereas in 5.3 it's only
"/:foo/:bar/"Generic inference has always been willing, in other cases, to produce a string literal union:
declare function choose<T extends string>(x: T, y: T): T; // p: "a" | "b" const p = choose("a" as const, "b" as const);so it's at least somewhat apparent that the 5.3 behavior is the incorrect (or at least inconsistent) one.
- addedNot a DefectThis behavior is one of several equally-correct optionsThis behavior is one of several equally-correct options
on Feb 1, 2024 typescript-bot commented
on Feb 4, 2024 ContributorMore actionsThis issue has been marked as "Not a Defect" 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
🔎 Search Terms
5.4 regression
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.4.0-dev.20240129#code/KYDwDg9gTgLgBDAnmYcCiIZQIYGMYBKEArjMAArY4C2AzgDwAqcoZAdgCa1y1YCWbAOYA+OAF4e-IS0zBO3RgFgAUHDgB+OAWC5oHerygDBAGklGhwlWoBccZqzlc4AAwAkAbwEAzYFDgA+gDKMFQwAL42nj5+cJQ04QD00Wy+-tq84S7WGnAecADaANZwAnFU2NRwAD5wRcCIEN7omDj4RKQUFXT0GTDCALp2hsZw4Tl2DrLyrilpgSFhkXOx8ZVZOZr5xaVs5TRD5qPjqnB2HuEA3CoqHDoANlSo3sRs+HwQe-cCRUwy7M4RpYABQ5KiCWjnHJqMDYGAAC0m11O4TgADI4MCLv8nNwMFg8IQSGQ1j1GKItnBYTRaOpzqjUecqd1IS0Ce1iV0aUxROEAJQmFR8uwANwgfA4yJUiUSLCgUGguwQ3AArAA6ADMmrg2E4cHVABY1QAGAC0ACNgKEVN82EUscyEXYAOSJGzeCAQN3mqjOszUyqs7H85EyuUK-xlGCqzWasxsCDhxVRmNGs2W0JquBBeEke4cOCWnV7PwRtU2n4O2FOuCu92e71URJ+5k0pkeiAujvOsZjPnIoA
💻 Code
🙁 Actual behavior
The last line is only an error in TS 5.3.3, not TS 5.4-beta.
🙂 Expected behavior
I'd expect it to be an error in both (
fooisn't specified).Additional information about the issue
Putting
NoInferin the conditional type makes the expected error reappear:So perhaps this is WAI? Just wanted to flag it as a change I noticed from 5.3.3 to 5.4-beta.