Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to TSC transformer instead of Babel by default #4938

Closed
devongovett opened this issue Jul 26, 2020 · 10 comments
Closed

Switch to TSC transformer instead of Babel by default #4938

devongovett opened this issue Jul 26, 2020 · 10 comments

Comments

@devongovett
Copy link
Member

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:

  1. Switch a large TypeScript project to use @parcel/transformer-typescript-tsc for .ts and .tsx files instead of babel, and measure the performance impact.
  2. If the perf impact is manageable, switch the default config over to TSC. Otherwise, discuss other options.
@mikeplus64
Copy link

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.

@devongovett
Copy link
Member Author

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.

@aminya
Copy link
Contributor

aminya commented Aug 23, 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 performance.

@LukeTOBrien
Copy link

tsc - Compiling TypeScript as nature intended.

@lgarron
Copy link

lgarron commented Dec 5, 2020

  1. Switch a large TypeScript project to use @parcel/transformer-typescript-tsc for .ts and .tsx files 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?

@mischnic
Copy link
Member

mischnic commented Dec 5, 2020

Is it worth filing bugs now

Yes

@lgarron
Copy link

lgarron commented Mar 11, 2021

Is it worth filing bugs now

Yes

I've given this a a go again, and this time I think I'm getting a TypeScript 3 compat error? Is that expected / worth filing an issue for?

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/typescript
npm ERR!   dev typescript@"^4.0.2" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer typescript@"^3.0.0" from @parcel/[email protected]
npm ERR! node_modules/@parcel/transformer-typescript-tsc
npm ERR!   @parcel/transformer-typescript-tsc@"2.0.0-nightly.625" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /Users/lgarron/.cache/npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/lgarron/.cache/npm/_logs/2021-03-11T11_40_11_289Z-debug.log

@mischnic
Copy link
Member

@lgarron I think that's already reported here: #5978?

@devongovett
Copy link
Member Author

devongovett commented May 30, 2021

An update on this: We are now transpiling TypeScript with SWC by default as of #6230. It is an order of magnitude faster than both Babel and TSC. It also fixes several issues that people had with using Babel as a transpiler for TypeScript. I think this changes the equation for what should be the default in Parcel significantly. Perhaps we should attempt to read tsconfig.json and apply the settings to SWC, as well as enable TS-specific transforms by default (e.g. decorators), but I no longer think using TSC by default is a good idea as it would harm performance significantly.

@devongovett
Copy link
Member Author

As of #6501 we are loading some settings from tsconfig.json and applying them via SWC. Currently we support settings for JSX and enabling decorators, which are the only compiler features that have to be enabled and are not part of the default configuration. As more experimental features are added, we will also support those.

Going to close this issue. If you want to use TSC, you still can by using @parcel/transformer-typescript-tsc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants