[poink]

If you maintain a popular public project, you help the entire JavaScript community if you use TypeScript, because then you can ship perfectly accurate type definitions along with your code. Even if the user is using plain JavaScript, their editor can probably use those type definitions to provide coding assistance.

Also, it's hard to call something a "leaky abstraction" when it's a superset of the thing it sits atop.

[reverentgeek]

True, it's not the same kind of leaky abstraction you find with other technologies. I'm thinking more about the newcomer to JavaScript/TypeScript, who has only focused on the latest language features, trying to get a grasp of what is going on in the ES5-compatible code that gets generated.

Same is true with relying on Babel, of course.

[WorldMaker]

More so than any random Babel preset someone might hand a new developer, though, Typescript has been pretty strict at this point towards staying strictly to ES Stage 3+ proposals. (And the few exceptions [enums, namespaces] are all common JS patterns that just about anyone should recognize the generated code, and are easy enough to avoid if you want to be more strictly ES Twenty Xteen+Types.)

(Also, the current Babel wisdom of "last two browser versions" suggests that ES2015 or ES2016 is the compatible downlevel of choice in 2019, rather than ES5.)

[ng12]

Absolutely. It's by far the easiest way to ship an easily consumable API reference with your library.

[shados]

It's leaky in the sense that you can bypass it. If I flag something as private in TS, there's nothing stopping a "any" somewhere from making it writable, for example.

[BoorishBears]

That's not what a leaky abstraction is.

[shados]

An abstraction that doesn't properly hide what's under the hood and requires people to still be aware of it. That's exactly what TS is.

[BoorishBears]

Ts doesn’t abstract away Js.

It’s a superset of Js, almost the “opposite” of an abstraction (at least in the common intent of an abstraction)