Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ordering sensitivity of exported enums and usages #2594

Closed
robertknight opened this issue Apr 2, 2015 · 6 comments
Closed

Ordering sensitivity of exported enums and usages #2594

robertknight opened this issue Apr 2, 2015 · 6 comments
Labels
Breaking Change Would introduce errors in existing code

Comments

@robertknight
Copy link

With default compile settings, the following works under TS 1.4 but fails under TS 1.5.0-alpha due to Color being undefined until the code generated for the exported enum has been evaluated because the default output for enums changed from emitting constants to references to 'Color.Red'.

// compile with 'tsc -m enum.ts'

var value = Color.Red;

export enum Color {
    Red
}

I'm unsure if this is considered a bug or simply a compatibility hazard to document?

@mhegazy
Copy link
Contributor

mhegazy commented Apr 2, 2015

This worked because in 1.4 we aggressively inlined enum values. Now this only happens for const enums and not regular enums.

It is also worth nothing that the general case never worked in 1.4, e.g.:

var value = Color.Red;

export enum Color {
    Red = 1 << 1
}
``
would emit:
```js
 var value = Color.Red;
    (function (Color) {
        Color[Color["Red"] = 1 << 1] = "Red";
    })(exports.Color || (exports.Color = {}));
    var Color = exports.Color;

which would have failed as Color is not defined.

I think this is a good candidate to be handled in #21, making it an error to reference a non-const enum before its declaration.

@mhegazy mhegazy added the Breaking Change Would introduce errors in existing code label Apr 2, 2015
@mhegazy mhegazy added this to the TypeScript 1.5 milestone Apr 2, 2015
@robertknight
Copy link
Author

Proposal in #21 sounds good to me. I was impressed that this was the only breakage in a 20K loc codebase updating from TS 1.4 to 1.5 - enjoying the ES6 awesome sauce.

@chinhodado
Copy link

So is the workaround export const enum Color?

@mhegazy
Copy link
Contributor

mhegazy commented Jun 4, 2015

@chinhodado it is up to you, using const enums means that the enum will be completely erased, and constants propagated at compile time. so Color does not exist at runtime.

@chinhodado
Copy link

That certainly is not what I want, since I also need reverse enum lookup (like var color = Color[1]).

In short, how do I get back pre-1.5 enums semantics? Or what are the recommended ways to create and work with enums in 1.5+?

@mhegazy
Copy link
Contributor

mhegazy commented Jun 4, 2015

Your only workaround is to make sure the enum is defined before it is used. The compiler should warn you about that (tracked issue #21), hopefully we can get this in the next (TypeScript 1.6) release;

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Breaking Change Would introduce errors in existing code
Projects
None yet
Development

No branches or pull requests

3 participants