preserveConstEnums does not preserve const enums from ambient declarations

[csnover]

// ambient.d.ts
declare module 'f' {
    export const enum A {
        A0 = 0,
        A1 = 1
    }
}

// g.ts
import f = require('f');
var a = f.A.A0;

Run: tsc -m commonjs -t es5 --preserveConstEnums ambient.d.ts g.ts

Expected output of g.js:

var f = require('f');
var a = f.A.A0;

Actual output of g.js:

var f = require('f');
var a = 0 /* A0 */;

Version: 1.4.1, 1.5.0-pre 9f49a16

[basarat]

Sorry, I should have mentioned duplicate of : #1812

[csnover]

Is it? That one seems like the opposite issue. Well, in any case. Here’s another test case!

[basarat]

Is it?

I am not clear either (I only know of inconsistency in the defaults used by language service vs. command line tsc : #1812 (comment))

[vladima]

preserveConstEnums flags controls if output .js file will contain definition\reverse mapping for const enums, normally these definitions are not emitted. Property accesses to members of const enums are always inlined

[basarat]

Property accesses to members of const enums are always inlined

The language service is not inlining. That is we get ts.EmitReturnStatus.Succeeded instead of 0 /* Succeeded */ from language service build output.

[csnover]

Sorry, I guess I totally misunderstood the purpose of this flag. I thought it was intended to keep the enum references as well. I guess then …edit this ticket into a request to have an option to do that?

Basically, at the moment, it’s impossible to create pre-compiled versions of portable libraries, since the enum values of a dependency might change across versions even though the enum keys are the same. (This happened in the TS language services from 1.4 to 1.5.)

[RyanCavanaugh]

Exposing a const enum outside a compilation unit is totally inappropriate if the version-to-version key->value mapping is not guaranteed (this is a rule you'll have to enforce yourself). const enum has the same rules as a C++ enum in this regard.

The 'option' for always using property references for enum members is to not use const enums 😉

We shouldn't have broken a const enum value between versions. Which one changed specifically?

[csnover]

We shouldn't have broken a const enum value between versions. Which one changed specifically?

SyntaxKind

[csnover]

The 'option' for always using property references for enum members is to not use const enums 😉

Ugh, of course, I don’t even… some days.