LS#getEmitOutput misses constant enum values on second emit

[jrieken]

• have two external modules (a.ts which defines and exports an enum, b.ts which uses the enum)
• emit the JS code for b.ts
• emit the JS code for a.ts and notice that the enum reference is inlined (console.log(0 /*A*/);)
• change a.ts and emit only that file again
• => now the enum is not inlined anymore (console.log(Foo.A);). I can debug this into checker#getConstantValue which discovers the enum value but fails to find a proper node link. I guess this is because changing a.ts cleared some type caches)

a.ts

import Foo = require('./b');
console.log(Foo.A);

b.ts

enum Foo {
    A = 0,
    B = 1,
    C = 2
}

export = Foo;

[mhegazy]

this is by design, as we do not track references to const enums. you will also run into the same issue with module properties:

a.ts

module m {
     export var x = 0;
}

var x = "global";

module m {
    console.log(x); // m.x, and not global x.
}

Now if you call getEmitOutput on a.ts, then b.ts then edit a.ts to remove the export for x, b.js still references an undefined m.x.

This is ok if you do not rely on incremental build as the only build system. I think we need a proposal for this.

[mhegazy]

@vladima should have a flag for this.

[CyrusNajmabadi]

"This is ok if you do not rely on incremental build as the only build system"

I disagree. I don't think it's ever been 'by design' that Incremental Build produce different output than the normal build. It's not acceptable for our incremental approach to result in different code that can then be broken or be hard to track down. As such, i view this purely as a bug.

We already aim for 100% correctness with Incremental Parsing, and we also aim for 100% correctness with --watch compilation. Incremental compile should be at that same bar as well.

[vladima]

This issue should be resolved with 79272d7 - now regular enums are never inlined and always emitted as property access