Provide an option not to use babel transform on typescript code

[piscisaureus]

Starting with parcel 1.6, all javascript code is transformed by babel.
Our project (https://github.com/propelml/propel) uses typescript, which already knows how to target different versions of javascript/ecmascript.
Therefore the babel transform is unnecessary -- and it actually creates problems because babel generates code that is dependent on regeneratorRuntime.
Could there be an option to disable the babel transform (either for typescript or for all javascript code)?

[davidnagli]

I agree. Typescript already handles transpiling code, so it doesn’t make any sense for us to run that through Babel. It just makes the bundle larger and wastes time duplicating the work that Typescript did.

We should also optimize the way we handle typescript assets too. Maybe we can even take the AST from the TypeScript Compiler API, and pass it into Uglify similar to what do with Babel.

[DeMoorJasper]

@davidnagli The AST is different from the babel AST, so this would be impossible, however this feature can be achieved by either converting Typescript AST to Babel AST (might be slightly faster if done correctly, but way more complex). Or generate a new AST from the output (kind of what we do now but without the actual transpiling)

[fathyb]

I started working on this on the TypeScript plugin, see parcel-plugin-typescript#c511bd.
Babel isn't called once, it's direct TS code -> TS AST -> transformations -> TS AST -> JS, with a support for fs.readFileSync, require, import, process and node.js globals.
On my big corporate projects it improves build time by a 1.5 factor.

We can create a PR for this here if you are interested.

[davidnagli]

Ya I think that would be a great idea.

I never really understood why we have a seperate plugin if we have Typescript support in the core. I think we should merge the plugin’s features into core and get rid of the plugin.

@devongovett @DeMoorJasper Thoughts?

[DeMoorJasper]

@davidnagli The direct typescript ast transform would be nice, more predictable as well. About porting over all the plugin features wouldn’t be a good idea, the plugin seems to go beyond parcels scope, another nice feature the plugin has is typescript error handling (and i don’t mean the annoying typing warnings, but actual compile-errors)

_{Sent with GitHawk}

[ry]

Yes please add this feature. Also (and I'm not totally sure if this is related but I think so) Parcel tends to swallow very obvious syntax errors. I love Parcel - but this is a deal breaker for me.
https://github.com/ry/deno/blob/5c7ba22f2242930ad09f011eaea12a59153e294f/deno2/BUILD.gn#L100-L101

[cerlestes]

Seriously, there needs to be an option to turn off babel. I don't want babel. I'm getting errors left and right because of some exotic libraries that TypeScript can handle to transpile correctly, but babel then messes up.

Is there a way to disable babel via .babelrc? I couldn't find one.

Please don't make me go back to webpack and its insane config.

[devongovett]

Parcel compiles code to the specified browser/node version target in your app. It determines this based on the browserslist or engines.node keys in package.json depending on the --target flag. If neither of those are available, a default is picked: > 0.25% marketshare for browsers, or the node LTS version (currently 6). If you want to disable compilation, you can specify higher engine versions in your package.json.

[screendriver]

@devongovett I created a .browserslistrc directly in my project root directory and filled it with

> 1%
last 2 versions
not dead

But unfortunately I'm still getting following error when I try to do a await import('./...'); in my TypeScript project:

Uncaught ReferenceError: regeneratorRuntime is not defined

It seems that Parcel is still using Babel and tries to find its regeneratorRuntime (that I don't use because of TypeScript has everything included for async / await and dynamic imports)

[bre7]

Same. Is there no workaround for this bug/missing feature ?

[gabrielDevlog]

hi guyz. First thanks for the huge works, parcel is becoming my bundler n°1 !

I'd like to add a +1 for this issue.

I'm using typescript for type-checking. That's why I expect parcel to

• fail on typescript error
• display typescript error on cli
• display typescript error on browser (at least in console)

But as explained here babel is only meant for transportation, not type checking. So typescript looks like the only way to go.

Currently I am using tsc and parcel in concurrent thread, to have all features, as explained in this repo

[anjmao]

I think we need to create a bundler which works out of the box with Typescript and doesn’t use Babel when not needed.

[screendriver]

@anjmao there is already one: FuseBox

[agonbina]

That's what we need, yet another bundler!

[icek]

At this moment, the workaround is adding the following lines to the package.json:

"browserslist": [
  "last 1 Chrome version"
],

[youk]

I guess it can be closed now that #6230 is implemented.

[DeMoorJasper]

Oh this was possible from the start with Parcel 2, can definitely be closed