3 ms·

I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, an

I'm in the camp that Babel 6 was "useless by default" in the bad sense. It's great that when you use tsc you know exactly what features are supported or not, and don't have to change anything, or worry about compatibility between things. And I'm starting to all the babel-preset-* packages have just created a bunch of busywork for the maintainers. Then there's the issue of tooling requiring Babel. react-hot-loader should not require Babel. graphql tooling should not require Babel. I'd argue when you're knee-deep in Babel, you're no longer writing JS, you're writing BabelScript. Only your BS capabilities are different than Jane's BS capabilities, which are also different from Bob's setup over there.

Vinnl 6y ago
Ah, I hear you - I'm not a fan of enabling a bunch of arbitrary Babel plugins either. But many metaframeworks (Next.js, Create React App) use Babel behind the scenes and use its TypeScript plugin for out-of-the-box TypeScript support. That's very useful, as long as the libraries you use don't use any of the Babel-incompatible features - which is most of the time, but not for TypeORM. So yes, it's exactly because I don't want to be configuring all kinds of language support for my projects that I'd recommend being able to work with (plain!) Babel with a TypeScript plugin.