Parcel: Parcel 2 should require less manual configuration of Babel to build Typescript (with decorators)

[uglycoyote]

🙋 feature request

I request that Parcel 2 require less manual configuration of Babel to work with Typescript.

In Parcel 1, Typescript mostly worked for me out of the box the way that I wanted it to, in a "zero configuration" way. It was a long time before I even realized that Parcel was using Babel under the hood to transpile, rather that tsc.

In Parcel 2, I immediately had a bunch of difficulties with my Typescript code which tool a long time to resolve, and it took me a lot further in to the weeds of configuring Babel and installing Babel plugins than I would have liked.

Specifically, my code uses "decorators", which did not work out-of-the-box with Parcel 2.

The error message about this was reasonably clear about the problem but not terribly clear about the solution.

@parcel/transformer-babel: Support for the experimental syntax 'decorators-legacy' isn't currently enabled (6:5):

From this, and doing some googling, I gathered that I needed to have a .babelrc file which contained the following in the plugins section:

      ["@babel/plugin-proposal-decorators", { "legacy": true }],
      ["@babel/plugin-proposal-class-properties", { "loose" : true }]

but unfortunately when I did this I started getting syntax errors:

Uncaught SyntaxError: Unexpected token '<'

So it took a bunch more googling to figure out that I would need to add @babel/plugin-transform-react-jsx to the plugin list. Since JSX worked correctly out-of-the-box, it took me a while to realize that I had inadventently broken JSX by creating the .babelrc. By creating the .babelrc to solve the decorators problem, I lost the settings which allowed it to process JSX.

I gather from #3911 that this behaviour has changed between Parcel 1 and 2, where in parcel 1 it merged your .babelrc and the Parcel default one where in Parcel 2, the project's .babelrc will override the default one. While I can see how the old behaviour might have created some issues with incorrect merging, the new behaviour is also troubling because I lost good defaults like the JSX processing, and I had to spend extra time researching how to re-add that functionality.

💁 Possible Solution

Here are a few possibilties on how the situation could be improved:

• Parcel's default babelrc could include the support for "experimental decorators" like it presumably did in Parcel 1 (my decorator code works fine in Parcel 1 without manual babelrc configuration). Why was this removed?
• If there's a good reason not to include decorator support by default, and if Parcel is going to attempt to be "zero-configuration" by configuring babel for the user out of the box, then Parcel could be smarter about whether to include decorator support by checking the tsconfig.json to see if the experimentalDecorators setting is true, and then configure babel accordingly.
• Parcel 2 could go back to the old behaviour of Parcel 1, merging the .babelrc project customizations with parcel's defaults. (I'm not sure what the issues with that approach were, but is the new approach really the lesser of two evils?)
• There could be an "eject" feature which writes out parcel's default configuration to the .babelrc file as a starting point, if the user wants to customize it. (Even after I read #3911 and knew that creating the .babelrc would override the defaults, I was having a hard time figuring out what the defaults were. I could not find the default .babelrc settings by doing a search of this repo)
• Consider using tsc as the default transpiler for Typescript, to avoid issues due to Babel ignoring tsconfig.json and/or transpiling differently than tsc would. (debated extensively in #4022). I'm supportive of both sides of this debate. I see the performance benefit of using Babel by default, but also see that Babel is not looking at all like a "zero configuration" option for my Typescript code the way that it is set up in Parcel 2.
• Typescript page (https://parcel2-docs.now.sh/recipes/typescript/) could be more detailed about babel configuration issues. A lot of Typescript users aren't really familiar with using Babel to transpile, since they use tsc normally.
  
  
  
  • Add a link to the default .babelrc so that it is clear what the defaults are in case you need to override them like I did
  
  
  • Add more clarity over what features of tsconfig map to what features of Babel
  
  
  • Add an explanation of the .parcelrc snippet that is in there which has "@parcel/transformer-typescript-tsc" added to the transformers section. It is not clear what that is for, but I mistakenly thought it would solve some of my issues, when in fact it did not seem to be required.
  
  

[mischnic]

(With Babel 7.10, class properties will be enabled by default)

We already have this

{
    "presets": ["@parcel/babel-preset-env"]
}

which correcly applies the browserslist config from Parcel into Babel. We should somehow extend this mechanism to cover flow/ts/jsx as well.

So for now, you need:

{
    "presets": ["@parcel/babel-preset-env", "@babel/preset-typescript"],
    "plugins": [
        ["@babel/plugin-proposal-decorators", { "legacy": true }],
        ["@babel/plugin-proposal-class-properties", { "loose": true }],
        ["@babel/plugin-transform-react-jsx"]
    ]
}

(I'm not sure what the issues with that approach were, but is the new approach really the lesser of two evils?)

One example: if you specified a preset that included the jsx plugin with a custom pragma (e.g. a CSS-in-JS framework), Parcel's default JSX would override that pragma.

And: there was no way to disabled preset-env.

Typescript page (parcel2-docs.now.sh/recipes/typescript) could be more detailed about babel configuration issues. A lot of Typescript users aren't really familiar with using Babel to transpile, since they use tsc normally.

Noted

Add an explanation of the .parcelrc snippet that is in there which has

As the first line of that page tells you, "TODO" 😉