Since TypeScript has the ability to generate a JavaScript bundle using the TypeScript compiler, are there still reasons to bother using babel and w...
For further actions, you may consider blocking this person and/or reporting abuse
One important aspect of babel-preset-env I think you missed: Browser Polyfills. TypeScript can transpile syntax down for older browsers, but it won't add runtime code to support something like String.prototype.replaceAll() in IE11
I've noticed in TypeScript playground, when you write code that contains newer features of JS and set the target to something like ES5, the
tscwill produce code that seems to be polyfilled. Why do you say that it doesn't do runtime polyfilling?Indeed, I will update the post this weekend to add this point 👍
I thought that TypeScript added polyfills, but it doesn't and adding them is not trivial either.
Thanks !
Great article! Babel is totally still useful, there are a lot of things babel can do over tsc, like literally anything. Until typescript has a plugin system where you can easily include extra transpilers and parsers, babel will always be the more flexible option. If anything I feel like since the typescript preset came out, the question should be "do we still need tsc?"
Honestly, I view
tscas a "proof of concept" compiler at best - incapable of even linking an npm package, it has honestly never been of any real practical use on real projects in the real world.It's useful for the language service and for type-checking with
--noEmitand not much else.It's kind of sad, really. The compiler itself is like a frustrating teaser - just enough to get someone trying out TS and get them interested, but not enough for them to actually do anything really useful at all.
It gets to the point of poignant, really - the fact that the Playground allows you to import from npm packages, but not actually run the code... I don't know whether to laugh or cry.
They ought to either retire it or at least add basic support for linking dependencies. 😕
Thank you !
Pretty much my conclusion indeed, I don't see a scenario where using tsc for the transpiling phase is better now?
But it was not obvious at a first glance, as the reddit answers and my own interrogation shows. Maybe that's because as you said, at the beginning of TypeScript, Babel wasn't an easy option since the TS plugin didn't existed
By any chance could you link or provide a (minimal) example of how to configure "use TypeScript compiler solely for the type-checking phase and Babel or SWC for the transpilation phase"?
I'm experienced with JS but relatively new to working with all the above, and with compilers in general. I've studied the basics of Webpack, Typescript and Babel, but am still not very clear on how they all fit together.
Thanks for any time you can offer on this!
This seems to be a good example: learntypescript.dev/12/l2-babel
Looks like the relevant parts are:
I'm in the process of figuring out a best practise for this too.
The approach you linked makes sense, but I'm still not sure where in the process typechecking is done.
Can we completely rely on our IDE to handle this for us? Do we need to run
tscmanually every now and then?It's a good question. I think the type-checking must happen "first"... ie Babel runs the TS checks, transpiles it to JS, then transpiles JS to ES5 (or whatever the settings are.) Check out this post: stackoverflow.com/questions/383202...
A helpful comparison is to a setup without
@babel/preset-typescript(ie: webpack applies TS, then Babel. (See this post: stackoverflow.com/questions/322343...)In this webpack.config.js, if the order of the babel-loader and ts-loader rules are reversed, the app crashes:
module: {rules: [
{
test: /\.(j|t)s$/,
exclude: /node_modules/,
use: {
// without additional settings, this will reference .babelrc
loader: 'babel-loader',
}
},
{
test: /\.ts$/,
exclude: /node_modules/,
use: {
loader: 'ts-loader'
}
},
Ah, also to your questions, with a webpack setup,
tscdoes not need to be run manually. It's also not needed to specifyoutDiroroutFilein.tsconfig- that is all handled by Webpack.Not so sure about the IDE portion of this, that is an added complication that often confuses me too. I've found it helpful to make a conceptual separation between code-processing (ie: webpack typescript babel), and looking-at-code (IDEs). Generally I think that once a language or plugin is installed in an IDE, it is supposed to look for the settings in your
.configfiles for any give project to know what to highlight. (But don't quote me on that.)Very interesting!
Thanks, very useful. I was wondering the same question but never bothered to properly investigate. What I am wondering if it still makes sense to use babel in component libraries, which are meant to be included in other projects backed with Webpack for example, which will will run through babel anyways. Many solutions (e.g. nx) suggest that you do.