Thanks for adding this @sandersn! Out of curiousity: how would the above @enum Target be expressed in TypeScript?

(disregarding the MISTAKE member)
For strings, there's no precise equivalent, because string enums are stricter than number enums in Typescript. That's because they don't allow computed values, so the compiler always knows which strings are legal. Here's the enum syntax:

enum Target {
    START = "START",
    END = "END"
}
Target.ERROR // error here
var target: Target = Target.START
target = "lol whatever" // error here!

You can also avoid the enum construct since it's not standard JS. There's more boilerplate in that case.

var Target = {
    "START": "START" as "START",
    "END": "END" as "END"
}
type Target = keyof typeof Target
Target.ERROR
var target: Target = Target.START
target = 'lol whatever' // error here too

But you can emulate @enum's behaviour exactly by declaring target: string:

var target: string = Target.START
target = 'lol whatever' // ok, target is just a string

If you don't care about values, you can also get the loose assignability behaviour with number enums, but they still only allow numbers to be assigned:

enum Target {
    START,
    END
}
var target: Target = Target.START
target = 'lol whatever' // error
target = 111 // ok

Edit: Unlike @enum, Typescript doesn't prevent you from mixing and matching strings and numbers as long as you give the values explicitly. And it only supports strings and numbers. @enum supports arbitrary types for its values.

Thanks! The 2nd snippet above (avoiding the enum construct) is my favorite.

@sandersn Is it common practice to change the number values of SyntaxKind? An AST parsed from an earlier version of typescript can't be processed with a newer version because it can't identify the SyntaxKind correctly.

@eps1lon Yes, this is common, and it's the reason we use --preserveConstEnums so that users can access ts.SyntaxKind.Foo instead of using a number literal.

@Andy-MS But the value of kind in a node is still a number. So if I compare ts@3.0.SyntaxKind.Foo with ts@3.1.SyntaxKind.Foo I will get false although they should be the same.

It's in general an error to mix-and-match two different TypeScript installs.

I keep hearing that but I have yet to find libraries that pin typescript to exact versions. This is also not documented anywhere and I feel like this should be the case because npm and yarn assume by default that packages follow semver.

Typically TypeScript would be a peer dependency (example: tslint) of a library that needs to require("typescript") (as opposed to just being built using it).