Babel 7 support

[verydanny]

Feature request

Support Babel 7

[davidnagli]

Ya we should definitely work towards introducing support for Babel 7.

The weird thing that surprises me is that you didn’t get an error!

parcel/src/transforms/babel.js

Line 44 in cafb6ef

if (parseInt(babel.version, 10) !== 6) {

We currently have a check that throws an error whenever you’re using an unsupported Babel version, so I’m thinking maybe your error is getting caused by something else it’s hitting before even starting the Babel transform. Did you get a stack trace with the error?

[DeMoorJasper]

@davidnagli possibly because he didn't have babel 7 installed locally

[verydanny]

Stack trace:

Server running at http://localhost:1234 
🚨  /Users/daniel/Git/21g/1zet/src/index.js: Cannot read property 'loose' of undefined (While     at _default (/Users/daniel/Git/21g/1zet/node_modules/@babel/plugin-transform-modules-commonjs/lib/index.js:21:23)
    at Function.memoisePluginContainer (/Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:113:13)
    at Function.normalisePlugin (/Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:146:32)
    at /Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:184:30
    at Array.map (<anonymous>)
    at Function.normalisePlugins (/Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:158:20)
    at OptionManager.mergeOptions (/Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:36)
    at /Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:265:14
    at /Users/daniel/Git/21g/1zet/node_modules/babel-core/lib/transformation/file/options/option-manager.js:323:22
    at Array.map (<anonymous>)

[DeMoorJasper]

@verydanny do you get the Unsupported babel version: ${babel.version} error if u install babel 7 in your project?

[verydanny]

I do not, and I do have babel 7 installed locally.

edit:

My package.json

{
  "name": "zeeto-new",
  "version": "1.0.0",
  "description": "new zeeto",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "scripts": {
    "start": "yarn parcel ./src/index.html",
    "build": "yarn parcel build ./src/index.html -d ./ --public-url ./"
  },
  "devDependencies": {
    "@angelrush/fm2": "^2.3.16",
    "@angelrush/react-components": "^2.1.5",
    "@babel/cli": "^7.0.0-beta.40",
    "@babel/core": "^7.0.0-beta.40",
    "@babel/preset-env": "^7.0.0-beta.40",
    "@babel/preset-flow": "^7.0.0-beta.40",
    "@babel/preset-stage-0": "^7.0.0-beta.40",
    "@babel/preset-stage-1": "^7.0.0-beta.40",
    "bootstrap": "^4.0.0",
    "flow-bin": "^0.65.0",
    "identity-obj-proxy": "^3.0.0",
    "node-sass": "^4.7.2",
    "parcel-bundler": "^1.5.1"
  }
}

[devongovett]

Ya, because the package name is @babel/core not babel-core in babel 7, so the error wouldn't occur.

[devongovett]

So, we need to figure out how to support both babel 7 and babel 6 simultaneously I think. Parcel will need to build projects built with Babel 6 for a while now, but we should also support Babel 7 projects and perhaps use Babel 7 internally.

Here's what I think we should do:

1. Once Babel 7 releases a final version, switch to it internally for parsing, running preset-env, transforming JSX, etc.
2. If there is a custom .babelrc config, detect the locally installed babel version in the app (babel-core version in package.json). We will need to require that babel-core or @babel/core is installed locally in the app if you want to use a custom babelrc.
3. If the babel version installed in the app differs from the internal babel version used by Parcel, do two separate compiles: 1 for the internal transforms using babel 7, and one for the custom babelrc. This may require a duplicate parse + codegen step if the Babel 7 ast is incompatible with Babel 6. 😦

This doesn't sound great actually. I wonder if we can get around it somehow...

[lifeiscontent]

@devongovett this might also help with typescript since babel7 has first class support for it now!

[elken]

I think a buildtime flag (for now at least) will resolve it.

parcel --with-babel7 or something similar.

[DeMoorJasper]

@elken That won't be neccessary if anyone would like to add babel 7 support we could just detect the version (the same way we already do to warn unsupported babel versions, with adding @babel/core to the check) and just try to support both.
Not sure how we'd achieve this, Devon already explained how he would approach it. Would be nice to not have to parse and generate 2 times.

[jeroenptrs]

Any updates on this? With new ES features on the horizon, it would be nice to be able to use Babel 7 instead of 6 (and let go of a lot of babel-plugin-transform-... dependencies)

[wachunei]

I'm literally just starting to learn parcel 😄. Is this issue the reason I come up with this error?

If so..

Why is @babel/helper-... being used by parcel dependency babel-core instead of a babel-helper-... compatible version? It seems like at this point it is necessary to have a duplication of old/new dependencies for internal/external babel transformation. Is this what Devon means? Sorry for the questions, I'm trying to get it right and help 😅

[DeMoorJasper]

It probably is due to parcel not supporting babel 7.
It would be nice to find a way to hotswap between babel-core and @babel/core without losing much of the performance.

[wachunei]

From the stack trace, parcel is actually using babel-core instead of @babel/core but what I do not get is why in this execution it requires a @babel- package instead of a babel. From what I understand, to support any babel (current or upcoming version), inner dependencies should be locked to a certain range (and dealing with the case of having "duplicated" dependencies). Does this sound bad? 😅

[pravdomil]

#475

[babakness]

Would be nice to have this, perhaps with a flag?

[vihanb]

adding babel core as peer-dep will allow users to have babel-core@7.0.0-bridge.0 meaning they can use @babel/core (v7) without dropping support for v6

[reccanti]

Any update on this?

[jeroenptrs]

@reccanti seems to me it's not being considered atm because it's not in the RFC Project Board (even though it's labeled as an RFC)

[DeMoorJasper]

@jeroenptrs we don’t really use those boards a lot. If a contributor wants to dig into this issue a PR will pop up, but my guess is it’ll be part of parcel 2

_{Sent with GitHawk}

[reccanti]

Gotcha, thanks for the fast response!

[DeMoorJasper]

First RC for Babel 7 has been released a couple hours ago as mentioned in #475 :)

If anyone is interested in researching how to support both Babel 6 and 7 feel free to do so

[vihanb]

I'm not too familiar with Parcel internals but couldn't babel7 be invoked based on presence of @babel/core module and otherwise runs legacy code?

[adrienharnay]

I'm not sure this can be done/is worth to fight for. The majority of projects I know have released a major version, and stopped supporting Babel6 since. However, if you think this could be achieved, I would be happy to lend a hand!

[DeMoorJasper]

@adrienharnay it would be cool if we could support backwards compatibility otherwise it might be part of parcel 2 which isn’t gonna get released any time soon

_{Sent with GitHawk}

[tunnckoCore]

and otherwise runs legacy code?

No.

is worth to fight for

Exactly, not worth.

If backward compat is so important... allow it through flag (--babel6?)for some months, then deprecate the flag anad remove it.

[DeMoorJasper]

@olstenlarck The flag seems to be a bit obsolete. The biggest challenge is making parcel support both, not detecting which one to use (we can probably detect it at the root and pass it along everywhere in the options object as described below).

If the user defines a babelrc file and/or has babel installed inside pkg.json you can derive pretty easily whether it's babel 6 or 7. (Either through version number or the @babel prefix/organisation)

EDIT: Parcel 2 will support both Babel 6 and 7 by turning asts back into code strings when the AST is incompatible. Which is currently impossible with the current architecture (or at least not in a clean way). Parcel should probably use Babel 7 internally as it probably gives us a little speed boost and keeps us up to date with the latest babel changes

[tunnckoCore]

First RC for Babel 7 has been released a couple hours ago as mentioned in #475 :)

@DeMoorJasper sooo, any way to try the things? It was closed so...

Parcel 2: Babel 7
Parcel 3: New parcel API + Babel 7

Sounds better.

[DeMoorJasper]

@olstenlarck the PR wasn't working perfectly and was no longer up to date.

We'll send an update here whenever we have anything worthy of testing

[adrienharnay]

Babel 7 has been released 😬

[DeMoorJasper]

Awesome, Babel 7 is finally out :)

Babel 7 support will be part of Parcel 2 as it will have the ability to check AST compatibility and stringify and parse based on whether it's compatible. (So we will support Babel 6, Babel 7 and any other compiler/transpiler that has a parcel plugin)

Not sure if it's possible to hack Babel 7 support into Parcel 1, but if anyone is up for the challenge feel free to try. (You would also have to stringify and parse and check compatibility, but I doubt you'd be able to make it possible in a clean way).

[devongovett]

WIP here: #1955. If you want to help, check out the to do list there and make PRs against the babel7 branch. Thanks!

[scrossan-crown]

I was wondering since babel 7 adds support for TypeScript would it possible to add type checking to parcel under a flag. Also if it could use the specified version of TypeScript in the projects package.json.

The reason I ask is I've been using fathyb/parcel-plugin-typescript for a while now but there hasn't been any activity on the project for around a couple of months and it would be great if TypeScript support it was built in.

[wongmjane]

Since Babel 7 supports transpiling TypeScript files, it could make transpiling in itself easier - let the Babel 7 compiler handle it, while tsc will only be used for type checking

Related Articles:

https://babeljs.io/blog/2018/08/27/7.0.0#typescript-support-babel-preset-typescript

https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/

[DeMoorJasper]

Using babel for ts would probably speed up compiling and fix some bugs in the process. However I think we should start by focusing on making babel 7 work properly for js

_{Sent with GitHawk}

[HauntedSmores]

Ran into this issue when trying to use Parcel's internal version of babel for my js but a different preset to run a gulpfile with ES6.

Is there a way to use a different .babelrc for Parcel vs gulpfile.babel.js?

[rafaelrinaldi]

@HauntedSmores For reference I know Rollup has a babelrc flag which you can opt out of. Might be worth checking if something like that makes sense in Parcel as well (I think it does).

[costinEEST]

As devDependencies I have installed

    "@babel/core": "^7.0.0",
    "babel-core": "^7.0.0-bridge"
    "parcel-bundler": "^1.9.7",

As peerDependencies I have this

"babel-core": "6.x || ^7.0.0-bridge.0"

But I still get the error Requires Babel "^7.0.0-0", but was loaded with "6.26.3" How can I fix it?

[tunnckoCore]

You can't, it's internal thing and we should wait... ;/

[JacobMGEvans]

Following.

ahahaha, thanks for the thumbs.

[codeaholicguy]

How is the progress of this? Babel 7.0 released 14 days ago. 😭

[shofel]

@codeaholicguy Nguyễn, You're welcome helping out with this! :) As I believe, #1955 is the starting point to participate on babel 7 support.

[devongovett]

Merged #1955 and released a beta in v1.10.0-beta.0. Please help test it out and report any bugs you find! 🎉

[devongovett]

I should have given some info about how it works.

• For internally generated configs, e.g. our built in babel-preset-env, and JSX support, we will use babel 7 automatically. If you don't have a .babelrc with custom plugins in it, you don't need to do anything at all.
• On existing projects with a .babelrc using babel 6, we will continue using babel 6 as normal. If you don't have an explicit dependency on babel-core in your package.json, one will be automatically installed for you.
• If you would like to move a project from babel 6 to 7, you need to add a dependency on @babel/core, and adjust your .babelrc to point to babel 7 plugins.
• For new projects, when you create a .babelrc file, we will automatically detect whether the plugins are dependent on babel 6 or 7 and automatically install either babel-core or @babel/core into your project for you. We also now support automatically installing the plugins themselves automatically as well. 💥

[qm3ster]

@devongovett

automatically installing the plugins themselves automatically

[Mike1stver]

I my friends, I have just create a project in babel by using this commands:

npm install -g parcel-bundler and
npm init -y

and npm install react react-dom.

As i understand, parcel will automatically use babel 7 for my configuration right? I did not use the .babelrc at all, however, i cannot use class properties i have this error:

Support for the experimental syntax 'classProperties' isn't currently enabled (5:19):

As i understand if parcel , in the way i configured, established babel 7 and not 6 for my project, @babel/preset-env will be installed and i do not need anything else to make the callProperties to works okey. How can I correctly select the version of babel? it seems the v6 is instaled and not the 7. which is the version a need indeed

[tunnckoCore]

There are two things: a) using v7 may still not be the default, or b) i'm not sure if the preset-env includes the class properties.

Hm, interesting.