Parcel: Switch to TSC transformer instead of Babel by default
We should measure the performance impact of doing this first. However, based on issues, it seems fairly clear that the Babel-based TypeScript support that we have now is too limited. @babel/preset-typescript doesn't enable all of the language features that TSC does, e.g. decorators, class properties, optional chaining, etc. This causes confusion for people.
We could either attempt to match the features that TSC supports in our default config, or just run TSC first, and then Babel like we did in v1. The main issue is that when you add a custom Babel config, you'd need to re-create our default yourself, which might also be confusing.
The action items here are:
- Switch a large TypeScript project to use
@parcel/transformer-typescript-tscfor.tsand.tsxfiles instead of babel, and measure the performance impact. - If the perf impact is manageable, switch the default config over to TSC. Otherwise, discuss other options.
devongovett
All 6 comments
I wonder if this is the best criteria for deciding if TSC is OK as the default. Mainly, I would be surprised if there are actually any large TypeScript projects that didn't have a tsconfig / use TSC already.
mikeplus64
on 27 Jul 2020
Having a tsconfig and using TSC for compilation are two different things. For example, you could have a tsconfig for type checking and editor integration, but use Babel for compilation. This is how popular tools like create-react-app and Next.js work.
devongovett
on 29 Jul 2020
I prefer tsc since it is "the main typescript" compiler. Build time is not a concern for me. I have never had any compiling-time issues in JavaScript. When you consider the time it takes to build a native application using LLVM for example, tsc vs babel becomes just negligible. You should not sacrifice the quality of the code and development just to cut the build time!
tsc has "incremental building" and "watch mode" built-in, which can increase the build time.
aminya
on 23 Aug 2020
tsc - Compiling TypeScript as nature intended.
LukeTOBrien
on 18 Nov 2020
- Switch a large TypeScript project to use
@parcel/transformer-typescript-tscfor.tsand.tsxfiles instead of babel, and measure the performance impact.
Suppose that we tried this on a moderately sized project and it failed. Is it worth filing bugs now, or if/when tsc is the default?
lgarron
on 5 Dec 2020
Is it worth filing bugs now
Yes
mischnic
on 5 Dec 2020
Related issues
davidnagli
路
3Comments
dsky1990
路
3Comments
davidnagli
路
3Comments
algebraic-brain
路
3Comments
termhn
路
3Comments
Most helpful comment
I prefer
tscsince it is "the main typescript" compiler. Build time is not a concern for me. I have never had any compiling-time issues in JavaScript. When you consider the time it takes to build a native application using LLVM for example,tscvsbabelbecomes just negligible. You should not sacrifice the quality of the code and development just to cut the build time!tschas "incremental building" and "watch mode" built-in, which can increase the build time.