-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
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. |
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. |
So is the workaround |
@chinhodado it is up to you, using |
That certainly is not what I want, since I also need reverse enum lookup (like 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+? |
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; |
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'.
I'm unsure if this is considered a bug or simply a compatibility hazard to document?
The text was updated successfully, but these errors were encountered: