Imported const enum is not inlined in generated code

[Jessidhia]

TypeScript Version: 2.4.0

Code

// a.ts
export const enum Foo {
  Bar = 'bar'
}

// b.ts
import { Foo } from './a'

Foo.Bar // TypeError or ReferenceError, depending on how it's compiled

Expected behavior:
Foo.Bar to be replaced with 'bar'

Actual behavior:
The import is deleted and Foo.Bar is left as is

[rbuckton]

@Kovensky, I cannot seem to reproduce this behavior in typescript@next or in our 2.4 release branch. This may have been fixed by another change. Can you verify against typescript@next? If you are still seeing this, we may need more information.

[Jessidhia]

It still happens with 2.5.0-dev.20170622.

It looks like --isolatedModules is causing the import { Foo } to be elided as a type import (correct), but is not replacing the Foo.Bar value in the processed source text. Disabling --isolatedModules generates correct code.

[DanielRosenwasser]

Unfortunately const enums are type-directed, but emit in isolatedModules is type-agnostic (it has to be, otherwise the modules couldn't be compiled in isolation).

[Jessidhia]

If that’s the case, then perhaps it should be an error to export them to begin with (at least in non-.d.ts cases). It’s not possible to make any meaningful cross-module use of them as it is.

[pwpatton]

in my d.ts file I declare a const enum and use it in an interface in that same file.

declare const enum LMListType {
  DEFAULT = 'default',
  SELECT = 'select',
  HELPER = 'helper',
}

interface LMListSpec {
  ...
  listType: LMListType,
  ...
}

I use it like this in my component code (angular4):
myComponent.ts:

if (this.listSpec.listType === LMListType.DEFAULT) {   
   etc...
}

Everything compiles but I get runtime errors since there is no LMListType. In-lining would fix this for me I think.

I could move my d.ts file to a regular ts file but then I have to import all of it's interfaces in each component that uses them. I'd like to avoid that.

What is suggested for this issue?

[lydia-schow]

I've also encountered this problem when transpileOnly: true. Without transpileOnly, I can't use multi-threading to speed up my webpack build (ts-loader, happypack, fork-ts-checker-webpack-plugin). Unfortunately, I'm dealing with +100,000 lines of legacy code, so removing all const enums is not feasible.

Typescript version: 2.6.1

[mhegazy]

I've also encountered this problem when transpileOnly: true. Without transpileOnly, I can't use multi-threading to speed up my webpack build (ts-loader, happypack, fork-ts-checker-webpack-plugin). Unfortunately, I'm dealing with +100,000 lines of legacy code, so removing all const enums is not feasible.

transpileOnly means transpile every file one at a time.. when the compiler is looking at one file, it has no way to know if the reference it is looking at is a const enum or not, since the declaration is in another file that it does not have access to..

so I do not think you can mix these two concepts, const enums (require whole program information), and transpileOnly (one file at a time).

[Jessidhia]

Which is why I now think that exporting a const enum should be a compile error.

[mhegazy]

yes. it should be an error under --isolatedModules. and this bug tracks adding that.

[BehindTheMath]

@mhegazy What about under --transpileOnly?

[mhegazy]

Not sure what you mean, but asserting that the code is safe to transpile one file at a time is what --isloatedModules do.

[mrcrowl]

When --isolatedModules is specified, could const enums instead be output as regular (non-const) enums?

[Jessidhia]

Either that, or they should not be allowed to be exported to begin with.

[jestarray]

Having this issue now with the vue cli. I don't know why but it was working before.. The correct settings are to turn the ts-loader transpileOnly: false and isoLatedModules: false and it should work ? Scratching my head because it was working fine until I set transpileOnly to true, which I flipped back to false but now none of it works...

//vue cli plugin typescript webpack config
 addLoader({
      loader: "ts-loader",
      options: {
        transpileOnly: false,
        appendTsSuffixTo: ["\\.vue$"],
        // https://github.com/TypeStrong/ts-loader#happypackmode-boolean-defaultfalse
        happyPackMode: useThreads
      }
    });

//exporting a const enum that aren't being inlined

export const Directions {
     UP
}

Alright, seems like mode has to be set to production. Guess I'll try to look into what happens in development later.

[bluelovers]

p7.zip

Version 3.8.0-dev.20200130

index.js

"use strict";

//import { Enum01 } from './temp';
//
//export const aa = {
//	a01: Enum01.A,
//}
exports.__esModule = true;
exports.bb = {
    a02: temp_1.Enum02.A
};

Enum02.A didn't emit as 0 or import temp.ts

---

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "CommonJS",
    "isolatedModules": true
  }
}

temp.ts

//export enum Enum01 {
//	A
//}

export const enum Enum02 {
	A
}

index.ts

//import { Enum01 } from './temp';
//
//export const aa = {
//	a01: Enum01.A,
//}

import { Enum02 } from './temp';

export const bb = {
	a02: Enum02.A
}

[funder7]

Hi, what's the status of this issue? Can it be considered resolved in v3.x ?

[theonlypwner]

@funder7 No, it hasn't been resolved.

I encountered this bug with TypeScript 4.0.2. For me, it caused ReferenceError at runtime, until I disabled isolatedModules in my tsconfig.json.

[nicolo-ribaudo]

Is this still a bug? When using --isolatedModules, the original code is now compiled to

export var Foo;
(function (Foo) {
    Foo["Bar"] = "bar";
})(Foo || (Foo = {}));

so it's available at runtime.

[Neonit]

Maybe related: local const enum member aliasing doesn't work either in Typescript 4.2.3 (can be observed on the official playground).

const enum N {zero, one}

import X = N;
const v0 = X.zero; // OK

import EINS = N.one; // either TS should complain here or compile it as expected

Compiles to:

"use strict";
const v0 = 0 /* zero */; // OK
var EINS = N.one; // ERROR

(Playground)

[silhouettesia]

Having this issue now with the vue cli. I don't know why but it was working before.. The correct settings are to turn the ts-loader transpileOnly: false and isoLatedModules: false and it should work ? Scratching my head because it was working fine until I set transpileOnly to true, which I flipped back to false but now none of it works...

//vue cli plugin typescript webpack config
 addLoader({
      loader: "ts-loader",
      options: {
        transpileOnly: false,
        appendTsSuffixTo: ["\\.vue$"],
        // https://github.com/TypeStrong/ts-loader#happypackmode-boolean-defaultfalse
        happyPackMode: useThreads
      }
    });

//exporting a const enum that aren't being inlined

export const Directions {
     UP
}

Alright, seems like mode has to be set to production. Guess I'll try to look into what happens in development later.

@jestarray when happyPackMode is true, transpileOnly is implicitly set to true

[jablko]

I think this issue can be marked fixed (since #40499):

• Not inlining const enums is the expected behavior if isolatedModules is true.
• const enum imports are stripped even with isolatedModules #40499 duplicated and fixed the reference error issue: The import was elided but enum usage was preserved.
• Inline const enum in import equals declaration #46664 aims to fix the reference error reported by @Neonit: Enum declarations are elided but import equals are preserved.

[andrewbranch]

It seems like we’re in a better place now with additional errors and isolatedModules implying preserveConstEnums, but I don’t see why isolatedModules should also prevent inlining const enums. The purpose of the flag is just to check that code can be transpiled one file at a time. There’s no reason, as far as I can tell, to make the emit worse when you’re doing whole-program compilation with tsc.