Literal number types of static readonly members break in declaration files.

[NaridaL]

TypeScript Version: 2.4.2 and 2.5.1

Code

class A {
  static readonly FOO = 1;
  static readonly BAR = 2;
}
type Foo = { type: typeof A.FOO, foo: number }
type Bar = { type: typeof A.BAR, bar: string }
type FooBar = Foo | Bar

function test(fb: FooBar) {
  if (fb.type == A.FOO) {
    return fb.foo
  }
}

Expected behavior:
This works as expected as-is, but if the test function is in a separate package it should work too.
Actual behavior:
In the generated .d.ts, the types of FOO and BAR are number, instead of 1 and 2 respectively. This breaks the discriminated union when it is used in a separate package which only references the .d.ts.

Workaround: When specifying the types of FOO and BAR explicitly, they are propagated correctly to the .d.ts.

[mhegazy]

this is a design limitation. type aliases are really just that, aliases. the declaration emitter tries to its best abilities to maintain these, but there is a limit to that.

[NaridaL]

@mhegazy I don't entirely get your explanation. The issue is that while the types of FOO and BAR (the static readonly members) are correctly inferred by TS to have the types 1 and 2 respectively, in the declaration file they have the type number. I'm not sure what this has to do with type aliases?

(Sorry if I made the issue unnecessarily complex with the discriminated union I was trying t give an example of where this is an issue.)

[kitsonk]

Yes, reducing it to a clearer item is that, at authoring time:

class A {
  static readonly FOO = 1;
}

results in A.FOO is typeof 1

When a declaration is emitted it becomes:

class A {
  static readonly FOO: number;
}

Which feels more like an issue in that the same type inference is not being made when the declaration file is generated.

Of course a work around is to simply assert the typings:

class A {
  static readonly FOO: 1 = 1;
}

And the emitted declaration file will be correct.

[mhegazy]

sorry, my bad. i thought the issue was type alias written as a literal type. this issue is already tracked by #15881

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.