ts-blank-space is a fast type-stripping compiler(bloomberg.github.io)
bloomberg.github.io
ts-blank-space is a fast type-stripping compiler
https://bloomberg.github.io/ts-blank-space/
48 comments
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.
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.
You can shove @ts-check on the top of js files and get some decent checks going on. It isn't 100% but it'll be pretty darn good.
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.
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.
You'd already be using source maps in any real-world scenario so I am not sure what's the value proposition here outside of "just for fun, I guess".
The tsc transpilation to lower ES versions is actually really useful when using not-so-recent Node versions. Not to mention this severely restricts TypeScript syntax to "just types" which isn't too bad but it means you now have to worry about yet another thing.
Then there's the ESM & CJS mess. You almost always want to export in both formats which will change a lot of the syntax, so this quickly falls apart for anything serious.
Just use esbuild if you want speed.
The tsc transpilation to lower ES versions is actually really useful when using not-so-recent Node versions. Not to mention this severely restricts TypeScript syntax to "just types" which isn't too bad but it means you now have to worry about yet another thing.
Then there's the ESM & CJS mess. You almost always want to export in both formats which will change a lot of the syntax, so this quickly falls apart for anything serious.
Just use esbuild if you want speed.
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.
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.
Cool. Reminds me of a similar program to convert python3 code to python2, which similarly converts the typing into spaces to preserve row and column numbers: https://github.com/abarker/strip-hints.
I wish enum was never part of TypeScript. It’s this one odd thing unlike the rest.
Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
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.
`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.
So, since they're now a part of JS - aside from namespaces and enums (which are discouraged) - none of those features generate code anymore.
Moreover, aside from namespaces and enums (which are discouraged), none of those features were incorporated into TypeScript until they were on track for inclusion into JS. They weren't taken from TypeScript and imported into JS; TypeScript took them from the ECMAScript people.
Being able to compile TypeScript by just stripping types has become a design principle of the language. For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
Moreover, aside from namespaces and enums (which are discouraged), none of those features were incorporated into TypeScript until they were on track for inclusion into JS. They weren't taken from TypeScript and imported into JS; TypeScript took them from the ECMAScript people.
Being able to compile TypeScript by just stripping types has become a design principle of the language. For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
Decorators and decorator metadata.
> For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
Yes, largely because ECMAScript has advanced so far relatively to where it used to be.
> For better or for worse, the TypeScript team steadfastly refuses to try to innovate on runtime language features at this point.
Yes, largely because ECMAScript has advanced so far relatively to where it used to be.
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
If a database engineer saw this schema:
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
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
I think string enums are actually totally okay considering they're interned and basically just pointers at the VM level, and then when you're debugging you don't need to figure out what the hell 0x72838ABC is.
Pointing to a lower level language with a different use case doesn't justify int enums to me.
Pointing to a lower level language with a different use case doesn't justify int enums to me.
That’s pretty much the last straw for why I switched to string unions. Debugging integers in logs was terrible.
Namespaces do as well, but I think it's just those two.
Oh right namespaces. Though I think those are considered deprecated? Or maybe just discouraged.
> We refer to the supported subset as Modern TypeScript because it represents nearly all TypeScript syntax, except for those TypeScript-specific features that may be considered legacy or discouraged in some way
> These unsupported TypeScript features already have preferred alternatives:
> Prefix-style type assertions (<type>value) should be replaced with as-style type assertions.
Am I out of date? Does someone know something I don't?
> These unsupported TypeScript features already have preferred alternatives:
> Prefix-style type assertions (<type>value) should be replaced with as-style type assertions.
Am I out of date? Does someone know something I don't?
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.)
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.)
I mean I have not seen anything to suggest that angle brackets are "legacy or discouraged"
They're discouraged because they conflict with JSX. For instance, in the eslint documentation:
> Most codebases will want to enforce not using angle-bracket style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.
https://typescript-eslint.io/rules/consistent-type-assertion...
> Most codebases will want to enforce not using angle-bracket style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.
https://typescript-eslint.io/rules/consistent-type-assertion...
The phrasing sounds a bit odd: surely "most codebases" don't use JSX, so why would they enforce anything JSX-related.
That's true, but this tool is made for users not using TSX.
(Or at least, they can't use this tool with it.)
(Or at least, they can't use this tool with it.)
I don’t think I’ve seen a single codebase using that pattern ever. With React being so popular and TS growing in popularity just about after React, people have settled on `as` assertions instead, whether they use JSX or not.
Doesn't the new node feature to strip types handle this already? https://nodejs.org/en/learn/typescript/run-natively
I haven't used it as I haven't had a need for it.
I haven't used it as I haven't had a need for it.
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.
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.
This is such a simple idea that it seems like it shouldn't work. Pretty nifty.
I'm a little confused about when I'd use this, if I'm quickly iterating on code as I develop it, probably I also want to know whether it type checks, right?
TS language server will do that for you as go along
Wouldn't that defeat the point of what static typing affords you? Before you "go along"?
No, during development your IDE will show you type errors and your dev server can ignore them. In CI tsc can type check. It's the best of all worlds: incorrect code will compile and work best-effort, you can see errors in your IDE, and CI will fail if it's incorrect.
You can have the code running in your browser instantly and have the typechecking happening in parallel while you develop.
> Today, it appears to be the fastest emitter written in JavaScript
JavaScript is really slow though compared to golang. For that reason I prefer esbuild for type-stripping.
JavaScript is really slow though compared to golang. For that reason I prefer esbuild for type-stripping.
I am shocked to not see a reference to Taylor Swift’s hit song Blank Space anywhere in the article!
> Skipping this work is what makes this a swift approach.
Hmm...
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
[deleted]
Still a nifty new tool though. I wish JS would just allow type declarations at this point. It doesn't need to enforce them, just allow them like Python does. That would be amazing.