Hacker News Reader

Comment by scrollaway | Hacker News Reader

As an uninformed typescript dev, can you explain to me how TS Babel support changed things? I understand its mechanical implications, but I don't see why it would matter for adoption.

View on HN

For example, it made it much easier for projects like Create React App to add optional support for TypeScript. When they added support, that just involved adding an optional extra step to the compilation process (checking whether you violated the type constraints) to make sure you actually get the benefits of TypeScript. Other than that, though, TypeScript projects using CRA use the exact same infrastructure when they use TypeScript, and the compiled output should be similar.

Before, this would have involved replacing Babel with TypeScript for transpiling. This means projects could have slightly different results depending on whether they were using TypeScript or not, increasing the surface area for bugs and adding an extra step to the debugging process.

Doesn't create react app use webpack behind the scenes?ts-loader already worked pretty well? Not sure how that affected anyone using Babel In a built pipeline, but the announcement made it sound like there were tons of people doing bespoke balbel-only builds.. Have not experienced that myself.

Yes, it uses Webpack. Its TypeScript support does not use ts-loader, which would be used in place of Babel loader - which would affect the team behind CRA, who would now have to maintain two sets of documentation, ask bug reporters whether they use TypeScript, etc.

TypeScript support as its implemented in CRA just uses Babel like it did before, with some minor modifications such as also passing it .ts files. In parallel, it also runs the ForkTSChecker plugin for Webpack, which notifies you of type errors you made - however, it would work just the same if that plugin was not activated. Hence, there is far less divergence from regular CRA projects.

Babel is a commonly used plug-in Webpack though. So I am guessing all projects that used Babel/Webpack got TypeScript support for free. It’s a TIL for me, definitely going to have to look into this. Sounds exciting.

Note that "TypeScript support" in Babel means that Babel can now strip the extra syntax that is part of TypeScript applications. It doesn't actually parse them.

A way to think about it is to consider TypeScript to be a linter, like ESlint - but one that you can help by annotating your code with e.g. the types of values you expect it to get passed. Babel can now strip those annotations before it transpiles your code, but you still need TypeScript to do the actual "linting". See https://vincenttunru.com/TypeScript-vs-Javascript

It’s more than a linter though. The Typescript compiler can handle the most common usage of Babel, namely targeting older runtimes.

If you set the build target to ES5 you can still use modern features like async/await and it will rewrite them using a regenerator function that runs on older platforms.

Sure, it can do that - but in CRA's setup, it doesn't; Babel handles that for you. Babel's TypeScript support allows CRA to re-use its Babel pipeline, and the linter metaphor was meant to help people understand that.

Like most metaphors, it's not a one-on-one match.

It's easier to plug it in because there's a lot of projects already using babel, so you just need to add a transformer. Previously you'd need to add a new step to your compilation process using tsc, which could be very difficult depending on how you built your project, especially if it wasn't Webpack-based.

For example, you _could_ use TypeScript before with React Native. But it was convoluted: there were 3 different way to do it, none of them perfect, and all really brittle. But with Babel 7, you just add another transformer to your babel file and bam, it's treated as a first class citizen. It's literally a one line change.

Yesterday's post about migrating to typescript [1] explains it well.

tldr: This release meant that adopting TypeScript no longer meant buying into the entire TypeScript ecosystem and that we could keep using Babel to emit JavaScript. More importantly, this meant that we could actually use TypeScript as a type checker, and not so much as a "language" per se.

[1] https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...

Reply on news.ycombinator.com