Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document themon our wiki's API Breaking Changes page.

Also, please make sure@DanielRosenwasser and@RyanCavanaugh are aware of the changes, just as a heads up.

Reading#59601 (comment), do we also need to banimport foo = x.y? Or is that erasable?

do we also need to ban import foo = x.y? Or is that erasable?

Modulo VMS restrictions, it always transforms toconst foo = x.y, but I would not categorize this as an erasure

ts-blank-space and Node both say no toimport Foo = Bar.Baz, so that mostly settles it.

Worth re-noting for people watching this that ts-blank-space and Node.js' Amaro currently do not handle uninstantiated (type-only) namespaces:

• https://github.com/bloomberg/ts-blank-space/blob/main/docs/unsupported_syntax.md#runtime-impacting-syntax
• https://github.com/swc-project/swc/blob/4ebea77cb86cb11c540eaeab30503ccdbd315690/crates/swc_fast_ts_strip/src/lib.rs#L1171-L1191

This disables ALL enums, but aren't string only enums 1 to 1 mappable to vanilla JavaScript? At runtime, as far as I can tell, a string enum behaves identical to an object composed of string values. Is this incorrect? And if not, would it be undesirable to allow string enums with this flag turned on? IMO string enums are far more ergonomic than const objects in that they are both a type and an iterable.

Sorry if this is irrelevant and the ship has sailed. Just thought I'd ask.

This disables ALL enums, but aren't string only enums 1 to 1 mappable to vanilla JavaScript? At runtime, as far as I can tell, a string enum behaves identical to an object composed of string values. Is this incorrect? And if not, would it be undesirable to allow string enums with this flag turned on? IMO string enums are far more ergonomic than const objects in that they are both a type and an iterable.

Enums are not "erasable" syntax - they need to be transformed to become valid Javascript.

An enum like this:

// TypescriptenumDirection{Up="UP",Down="DOWN"}

is transformed into

// JavascriptvarDirection;(function(Direction){Direction["Up"]="UP";Direction["Down"]="DOWN";})(Direction||(Direction={}));

The flag introduced here aims at ensuring you get a type error when you write typescript syntax that is incompatible with Node's new type stripping feature (https://nodejs.org/en/learn/typescript/run-natively#running-typescript-code-with-nodejs), which enums are.

(There is a new--experimental-transform-types flag in Node whichcan handle enums)

As@ptts says, erasable enums do not exist today.

There is a proposal to add them to TS via newas enum syntaxhere.

@alexbit-codemod We need a codemod for this so everyone can migrate away easily!

Should this option imply--verbatimModuleSyntax?

We discussed this heavily and settled on "no" for now, mainly because it makes our implied options complexity even worse, but also because it means those who are using this flag for reasons that aren'tspecifically needing the emit then have to disable some other flag (or if we made it required, be stuck).

I'm coming here fromthe 5.8 announcement, looking for how to migrate from enums when usingerasableSyntaxOnly.

A popular solution that I see is using anas const object (e.g.as documented in the handbook).

// you can also use number literalsconstMyEnum={Foo:"Foo",Bar:"Bar",}asconst;

This is usually accompanied withexport type (e.g. as intheas enum proposal):export type MyEnum = typeof MyEnum[keyof typeof NodeType];

This lets you useMyEnum as a type representing the union of the variant values (heretype MyEnum = "Foo" | "Bar") and on the value side you can useMyEnum.Foo orMyEnum.Bar.
There are a few downsides though:

• You lose nominal typing since the typeMyEnum is now equivalent to the string literal union, consumer can pass"Foo" directly as a literal (instead of explicitly usingMyEnum.Foo).
• You can't refer to the variant type throughMyEnum.Foo, this is mainly an issue when using the enum as the tag of a discriminated union
• Unless you use the variant name as the variant value, debugging is less convenient because there's no reverse mapping

I don't really care about the last point, and it's easy to use the variant name anyway (it will most likely be interned by the JS engine, so perf should not be a big concern when comparing using a number VS a short string).

On the other hand, I'd like to have a way to keep nominal typing and lightweight type syntax for variants. Here is what I ended up moving to:

constFoo:unique symbol=Symbol("Foo");constBar:unique symbol=Symbol("Bar");constMyEnum={  Foo,  Bar,}asconst;typeMyEnum=typeofMyEnum[keyoftypeofMyEnum];declarenamespaceMyEnum{typeFoo=typeofMyEnum.Foo;typeBar=typeofMyEnum.Bar;}export{MyEnum};

This usesunique symbol for nominal typing, which requires either astatic readonly class property or a simpleconst. Using a class prevents you from usingMyEnum as the union of all variant values, so constants must be used. I then combine it with a type namespace to provide type-level support forMyEnum.Foo.

Obviously, this approach is even more inconvenient at the implementation side, but I find it more convenient on the consumer side. The implementer side complexity is less relevant if using codegen.Symbol is also skipped inJSON.stringify for both keys and values, so if you rely on it then it won't work and you'd need a branded primitive type if you care about nominal typing. I use schema-guided serialization so it's not an issue for me, but it's worth mentioning.

The "record of symbols" approach addressesthe complaints in this blog post about support variant annotations such as@deprecated: you can annotate in the namespace, or the symbol values.

I hope this message helps others when evaluating available solutions when migrating away from TSenums.