Repository navigation
Broken emit when Infinity or ‑Infinity ends up in a type position #42905
Description
Bug Report
🔎 Search Terms
InfinityNaN- numeric
- literal
🕗 Version & Regression Information
- Tested in: TypeScript 4.1.5 and TypeScript 4.3.0‑dev
- I was unable to test this on prior versions because Number, enum, and boolean literal types #9407 was implemented in TypeScript 2.0.
💻 Code
// @declaration
// @showEmit
// @showEmittedFile: index.d.ts
// @filename: index.ts
export const PositiveInfinity: 1e1_000_000 = 1/0 as any;
export const NegativeInfinity: -1e1_000_000 = -1/0 as any;⏯ Playground Link
🙁 Actual behavior
TypeScript emits Infinity and ‑Infinity in a type position, which are intentionally invalid according to #9407 (comment):
// index.d.ts
export const PositiveInfinity: Infinity;
export const NegativeInfinity: -Infinity;🙂 Expected behavior
The Infinity and ‑Infinity values are valid in a type position, so that the generated .d.ts file is valid.
Also, it’d be nice to support literal NaNs, which would allow for Number.isNaN to be typed as:
interface NumberConstructor {
isNaN(number: unknown): number is NaN;
}Related issues
Reacted by Ricardo Fernández Serrata
Activity
[-]Broken emit when `Infinity` or `-Infinity` ends up in a Type position[/-][+]Broken emit when `Infinity` or `‑Infinity` ends up in a type position[/+]MartinJohns commentedon Feb 21, 2021
You're mixing a bug report and a feature request together in one. Fixing the bug would be to emit the type
numberinstead ofInfinity. Introducing anInfinity(andNaN) type is a feature request, for which you should provide a good reasoning in response to #9407 (comment).Jamesernator commentedon Feb 22, 2021
I for one have wanted
Infinity/-Infinityas a special case for things that otherwise take BigInts e.g. ranges:MartinJohns commentedon Feb 22, 2021
James Browning (@Jamesernator) Just as a general advice: It tremendously helps when you explain your reasoning on why you want this, not just say "I want it for this". In your example you could just as well replace the
Infinitywithundefined. Having a dedicatedInfinitytype would not help you in this case, becauseInfinitywould be a sub-type ofnumber, so the union typenumber | Infinitywould be simplified tonumber. Same as it happens withnumber | 5.Jamesernator commentedon Feb 22, 2021
The example is bigint not number. BigInts don't contain an
Infinityvalue, I think it's a lot more readable to use the explicitInfinityvalue rather than some arbitrary token as it already compares correctly with bigints (e.g.bigint < Infinityis alwaystrue, no coercion toNumberhappens).ca-d commentedon Apr 23, 2021
More compelling explanations for why these types are needed can be found in #28682 .
typescript-bot commentedon Dec 4, 2023
👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the repro in the issue body running against the nightly TypeScript.
Issue body code block by ExE Boss (@ExE-Boss)
Historical Information
👍 Compiled
Emit:
lionel-rowe commentedon Mar 4, 2025
Wouldn't it be emitting
1e999or something else that's allowed as a literal TS type but equivalent to IEEE 754 infinity? Emittingnumberis still wider than the original type.RyanCavanaugh commentedon Sep 6, 2026
This is fixed in current native TypeScript 7.1.0-dev.20260906.1. With
--declaration --emitDeclarationOnly, TypeScript 4.1.5 and 6.0.3 emitInfinityand-Infinity; consuming the latter reports TS1110 (Type expected).Current native TypeScript preserves
1e1_000_000and-1e1_000_000in the emitted declaration, which compiles cleanly.