You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
typeof with identically named type and value causes invalid .d.ts outputΒ #58390
Given how easy this is to repro, I'd assume this would occur often in the wild.
Issues like this that are only exposed in build output are also particularly insidious because most library authors don't explicitly check their build output, and most consumers use skipLibCheck, which would result in the affected type silently resolving to any.
Reacted by Riordan, whzx5byb, Leo Conforti, Patrick Roza, Michael Arnaldi, Adrian, Giulio Canti, Datner, Kristian Notari and accplan
Given that this was introduced before release wouldn't it be a better strategy to revert the commit that introduced the bug and defer that commit to 5.6? It feels a bit odd to introduce a bug, recognize that it is a bug and defer the fix till a further version. I would understand the choice if this didn't came up pre-release
Reacted by Adrian, Datner, Kristian Notari, Patrick Roza and accplan
Activity
Andarist commentedon May 1, 2024
Bisects to #57772
ssalbdivad commentedon May 2, 2024
Ryan Cavanaugh (@RyanCavanaugh) Is this not worth patching into TS 5.5?
Given how easy this is to repro, I'd assume this would occur often in the wild.
Issues like this that are only exposed in build output are also particularly insidious because most library authors don't explicitly check their build output, and most consumers use
skipLibCheck, which would result in the affected type silently resolving toany.patroza commentedon May 2, 2024
This would be quite a disaster especially considering this only occurs in the .d.ts which for libraries are often generated just before publishing.
mikearnaldi commentedon May 2, 2024
Following as Effect may be affected
mikearnaldi commentedon May 2, 2024
Given that this was introduced before release wouldn't it be a better strategy to revert the commit that introduced the bug and defer that commit to 5.6? It feels a bit odd to introduce a bug, recognize that it is a bug and defer the fix till a further version. I would understand the choice if this didn't came up pre-release
datner commentedon May 2, 2024
Hmm this matches a ton of common behavior, even the humble
as const"enum" is affected.This being broked^
though this works fine:
hmmmm
RyanCavanaugh commentedon May 2, 2024
Yeah, good points all around