ts-blank-space is a fast type-stripping compiler

At least Node.js has added experimental support that seems to do that: https://github.com/nodejs/node/pull/53725

But this is just an on-the-fly transpile(natively supported). It would be much better if JavaScript would go the Python route. For that they would have to extend the EcmaScript spec (to be safe) I guess.

Just using JSDoc is imho not a good alternative. The big benefit of TypeScript is that your compiler checks this all for you. I've seen to much incomplete or wrong JSDoc in my life.. also a nightmare to maintain.

There is a proposal for that: https://github.com/tc39/proposal-type-annotations

This feels like the sort of thing that would be nice to have ide support for.

Open a js file with ts comments, and it silently converts to ts editing. Save the file and it converts ts back to js with comments before actually writing.

All of your objections are addressed in the article.

> You almost always want to export in both formats

I haven’t exported CJS in half a decade. I haven’t authored CJS in a decade. You most definitely do not always want to do that.

> You'd already be using source maps in any real-world scenario

We're shipping production real-time genomics apps in vanilla JS with no source maps.

Agreed. It looks OK on the surface, but if you need enums then TS enums is going to end up in frustration.

Lots of TypeScript features generate code: namespace, async/await, yield, decorators, object spread, varargs, etc.*

`const enums` (beyond enums) are especially odd. They rely on type information to emit code.

* Subsequent to their release in TypeScript, EcmaScript versions now support some of these.

Here's a good video about TS enums: https://www.youtube.com/watch?v=jjMbPt_H3RQ

Strong disagree. enums + unions = ADTs. Without enums you have to use either string or number.

The problem with using strings is that nothing else uses strings (like say, your database), so you have to have this interminable roundtrip conversion between strings and integers.

JS programmers are in a bit of a bubble where using strings as enums is socially acceptable, if a C programmer saw this code

    typedef struct {
        const char* type;
    } Animal;

If a database engineer saw this schema:

    CREATE TABLE animal (
      id INTEGER PRIMARY KEY,
      type TEXT
    )

It's way nicer to use integer enums from A to Z, because everything else has enums and people use them.

If you use plain integers instead of integer enums then the compiler has no visibility into what your tags are. So your diagnostics will be hard to read because the compiler doesn't know that 69 is AnimalType.frog

Namespaces do as well, but I think it's just those two.

What's not explained by the quoted excerpt?

Instead of writing, e.g. `const n = <number>someValueThatYouKnowIsANumber;`, you should write `const n = someValueThatYouKnowIsANumber as number;`

(well, really, you shouldn't write either, casts are bad. But, yknow.)

It does!

Node uses swc to do this. The swc implementation of blank-spacing (implemented here https://github.com/swc-project/swc/pull/9144) was inspired by the author of ts-blank-space here: https://gist.github.com/acutmore/27444a9dbfa515a10b25f0d4707.... It has just taken a little longer to release the original implementation.

TS language server will do that for you as go along

> Skipping this work is what makes this a swift approach.

Hmm...

Same thought, surely it can't be a coincidence, maybe they thought it was so on the nose that it would be best to not draw attention to it.

Now they’ve just left us all with Bad Blood

Are you trying to get us sued?!