--erasableSyntaxOnly

[RyanCavanaugh]

Implements #59601

[typescript-bot]

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

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

[jakebailey]

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

[RyanCavanaugh]

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

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

[jakebailey]

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

[DanielRosenwasser]

JSX?

[RyanCavanaugh]

Open to suggestions 🤷

[jakebailey]

I'd vote no since that would curse anyone trying to use this for "purist" purposes to not being able to use JSX at all; you're already going to get an error from Node, and in other runtimes or with a loader, it might even work just fine....

[RyanCavanaugh]

Yeah, the fact that you already have to put JSX content in a .?sx file means you can't possibly make the mistake of "not realizing enum is special" or whatever.

I thought Daniel wanted the text to say something different, which technically JSX is a non-ES runtime construct, but the phrasing would maybe get super awkward

[jakebailey]

Ohh that interpretation makes a lot more sense, oops

[DanielRosenwasser]

you're already going to get an error from Node

Well you could make the same argument about all of these features right?

the fact that you already have to put JSX content in a .?sx file

Well we permit JSX in JS files 😄

[DanielRosenwasser]

Overall I think it is fine either way, just a slightly weird distinction.

[jakebailey]

The implementation seems right to me; cross checking with other tools, I don't believe we missed anything, but it might be a good idea to add a test that shows that namespaces need to be recursively checked.

[jakebailey]

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

[scottmas]

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.

[ptts]

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:

// Typescript

enum Direction { 
  Up = "UP", 
  Down = "DOWN"
}

is transformed into

// Javascript

var Direction;
(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 which can handle enums)

[robpalme]

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

There is a proposal to add them to TS via new as enum syntax here.

[mohsen1]

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