Issues with exporting and importing enums

[glazar]

TypeScript Version: 2.4.1

Code

file1.ts
export enum Colors {
  Red = "RED",
  Green = "GREEN",
  Blue = "BLUE"
}

export enum Numbers {
  ONE = 1,
  TWO = 2
}

file2.ts
import { Colors, Numbers } from "./file1";

Expected behavior:
Colors and Numbers should not be undefined in file2.
Colors should be:

{
  Red: "RED",
  Green: "GREEN",
  Blue: "BLUE"
}

Numbers should be

{
  ONE: 1,
  TWO: 2
  1: "ONE"
  2: "TWO"
}

Actual behavior:
Colors and Numbers are undefined.
Any enum entry requested fail with "Cannot read property 'enum entry' of undefined".
It seems that this only occurs in case of a circular dependency.
If you remove the circular dependency everything seems to work fine.

[kulshekhar]

@glazar is this similar to #112 ?

If not, would it be possible for you to create a minimal repo that reproduces this?

[glazar]

@kulshekhar
I do not know whether this is related to #112 or is another issue altogether.

I have created a small repo reproducing this issue.
Please have a look and let me know what you think.

This issue only happens for us only when running the unit tests.
We have worked around this issue by removing the circular dependency.
The problem is not visible when the code is bundled using webpack with ts-loader.

[kulshekhar]

Thanks for the repo. I was able to replicate this issue and dig into it a bit.

I think that this comment in the Typescript repo explains the cause of this issue.

Given that this is more of a Typescript issue, I'm not sure there's much we can do here

[bencompton]

From that comment, it appears that the TypeScript team has no intention of fixing this, and I don't really see how they could given that transpileModule has no consistently reliable way to resolve imports and access the enum definitions.

As this issue comment suggests, it isn't always safe to use transpileModule. I certainly understand the performance reasons why transpileModule was chosen for the preprocessor, though. The only solution I can think of would be to do a full compile ahead of time and then serve the transpiled JavaScript files as Jest requests them. That is not a trivial change, of course, and would require having a watch process in place as well.

[rikkit]

Would it be workable to change the preprocessor to use a different compiler api - but just passing in the test file and a preconfigured list of files containing const enums? Or would that still kill performance?

I remember a comment in another issue which suggested they rewrote the const enums after compilation using a webpack plugin - maybe that would be more viable?

[kulshekhar]

@rikkit if there's a workable solution, we can find a way to get that in

[goloveychuk]

faced with same problem. But not with enums but with using my library (https://github.com/goloveychuk/tsruntime) which uses custom transformers api.
It emits types metadata and requires types from imported module. So it's any everywhere.
So, as I see, two options to workaround

1. run program.emit with filelist of all files. But this will affect performance since it will compile same files many times.
2. use LanguageServiceHost compiler api, and compile all files before jest stage starts.

[goloveychuk]

https://github.com/goloveychuk/awesome-ts-jest
Proof of concept, which solves problem with imported enums and custom transformers.
With smart files updating (versioning) it should work pretty fast.

[GeeWee]

This might be solved by #505

[huafu]

You can test with beta version (see #697) which handles const enum and others thanks to the language service.