Babel 7 #1955

devongovett · 2018-08-29T12:28:44Z

This updates to use Babel 7 internally. Babel 6 will also be supported for projects that haven't upgraded yet. Fixes #868.

To do:

Support both Babel 6 and 7 at the same time.
Automatically install babel-core v6 in a project if we detect babel 6 plugins.
Load configs using Babel's helper methods
Use babel-preset-env's new polyfill useBuiltIns: "usage" option.
Ensure all existing tests pass.
Add tests to ensure babel 6 is still supported.

If anyone wants to help with any of these items, please make PRs against the babel7 branch. Thanks! 🙏

devongovett · 2018-08-29T12:29:11Z

src/visitors/matches-pattern.js

-// from babel-types. remove when we upgrade to babel 7.
-// https://github.com/babel/babel/blob/0189b387026c35472dccf45d14d58312d249f799/packages/babel-types/src/index.js#L347
+// from @babel/types. remove when we upgrade to babel 7.
+// https://github.com/babel/babel/blob/0189b387026c35472dccf45d14d58312d249f799/packages/@babel/types/src/index.js#L347


TODO: remove this file now that we are on babel 7 :)

tunnckoCore · 2018-08-29T13:25:31Z

I think we should have (as deps here) both Babel 6 and Babel 7 pacakges. Then detect if the cwd's package.json has babel- prefixed deps/devDeps, then use the v6 stack, otherwise use the v7 things.

I'm not sure if there is AST changes between v6 and v7? If not, then that would be great! Otherwise, that would be the most tricky and hard part. The rest is easy.

* Fix babel-types dependency name * Upgrade to Babel 7

devongovett · 2018-08-29T13:31:41Z

I believe there may be AST changes, not 100% sure though. cc. @hzoo @loganfsmyth

I was going to use babel 7 for all our internal parsing needs. Many parcel projects don't need any custom babel plugins at all since we generate a config using preset-env and preset-react already. But for those that do have a .babelrc, I was going to try to detect the versions of the plugins (from package.json) and if they are v6, then install babel-core v6 locally in the project and use that to run the custom transforms. If the ASTs aren't compatible, we'll stringify with babel 7 and reparse with babel 6.

hzoo · 2018-08-29T13:35:03Z

👋 There are a few AST changes but it's small https://babeljs.io/docs/en/v7-migration-api#ast-changes, mostly to match estree https://babeljs.io/docs/en/v7-migration-api#removal

devongovett · 2018-08-29T13:48:10Z

The AST changes look pretty minimal. I wonder if it would be faster to traverse and convert the AST to a babel 6 compatible one and back than to generate + parse + generate + parse. Should be pretty easy to write a converter.

hzoo · 2018-08-29T13:54:10Z

That would be essentially what babel-eslint does (parse with babel and then modify it to support espree/eslint), except it's for v6. https://github.com/babel/babel-eslint/blob/6aa8b6f02ff83cfb14eae2432f226f113929a50f/lib/parse.js#L90 Ideally we would just output a v6 compat mode so it would be faster but yeah not sure how there would be a good way of doing this.

tunnckoCore · 2018-08-29T14:00:16Z

Yea, 1) parse with Babel 7 always, then 2) convert them back to v6, 3) do the transofrms, 4) covert them back to v7 and use v7's stringify. Because changes are really minimal. Rest would be just the same.

I'm not very familiar with the codebase though, but just thinking. ;d ;]

DeMoorJasper · 2018-08-29T16:34:43Z

package.json

+    "@babel/preset-env": "^7.0.0",
+    "@babel/template": "^7.0.0",
+    "@babel/traverse": "^7.0.0",
+    "@babel/types": "^7.0.0",
    "ansi-to-html": "^0.6.4",
    "babel-code-frame": "^6.26.0",
    "babel-core": "^6.25.0",


Shouldn't this be localRequired as we'll use Babel 7 for everything internal?

(Or a devDep if we'll test this)

WIP for this: #1958

… hasConfig to handle arrays to check babel6 and 7

devongovett · 2018-09-16T06:11:07Z

Merged and published as a beta in v1.10.0-beta.0. Please help test this out and report any bugs you find! 🎉

tunnckoCore · 2018-09-16T15:02:29Z

Sweeet. So, in a new project it just works, right?

bkniffler · 2018-09-16T15:05:07Z

I just switched to v1.10.0-beta.0 and except for updating the babelrc file to use the later @babel plugins, everything works good.

loganfsmyth · 2018-09-16T18:05:49Z

@devongovett Cool, I'll respond to your issue when I get some time. I think some of they are reasonable requests.

I think my fundamental issue with your approach here is that it assumes that it is even possible to autodetect the version of Babel in use. While that may be try between 6 and 7 in most cases, that doesn't seem like a thing we can rely on long-term when Babel releases further major versions. Along with that, there's no guarantee that, as users migrate to JS-based config files, that config files will be parsable for metadata in the way you're doing now. Especially if tools start adopting things like Yarn's new proposed resolution logic, I'd expect that all config files will transition to requireing plugins first, meaning that their aren't any paths available for you to resolve anyway, at runtime, so it seems like the vast amount of the work you'd need to do to detect the version would have to be performed as static analysis on the config files, without even running them, and that's not something Babel can help you with.

I'm 100% behind Parcel's desire to be zero-config, but it seems like you want to be both zero-config and un-opinionated, and those seem directly contradictory. I think you should just update to use Babel 7 as a new major bump and drop Babel 6, and bump your major any time any new dependency version comes out.

devongovett · 2018-09-16T18:52:44Z

@bkniffler

except for updating the babelrc file to use the later @babel plugins, everything works good.

Does this mean something is broken using newer babel?

@loganfsmyth

While that may be try between 6 and 7 in most cases, that doesn't seem like a thing we can rely on long-term when Babel releases further major versions.

One of the things mentioned as part of the babel 7 upgrade was that all of the plugins and presets now have a peer dependency on the version of @babel/core that they need. This makes it pretty easy for us to auto detect the version of babel that Parcel needs to use. I think babel should enforce this requirement on third party plugins as well.

You're right that JS-based config files are problematic, and I think they are not really a great idea in general. Parcel will support them, but probably not quite as automatically as .babelrc. We cannot help auto install plugins, or detect the version of babel to use automatically in that case. I think if people want to use JS configs, then they are responsible for ensuring that all of their plugins are installed themselves, and that they have a dependency on babel core in their package.json prior to running Parcel.

devongovett · 2018-09-16T20:26:25Z

Also, @loganfsmyth @hzoo is the AST converter we wrote for babel 6 -> 7 and visa versa something that you think should exist in babel itself? I could see it being useful for other projects, and probably not something we should be maintaining in Parcel ideally.

loganfsmyth · 2018-09-16T20:14:11Z

src/transforms/babel/env.js

+      useBuiltIns: useBuiltIns ? 'entry' : false,
+      shippedProposals: true
+    }
+  ).plugins;


FYI, presets can have any of Babel's standard options, so you're throwing those away here. That means if we refactor this in the future to have other things, things will break in Parcel.

loganfsmyth · 2018-09-16T20:15:50Z

src/transforms/babel/config.js

+
+module.exports = getBabelConfig;
+
+function mergeConfigs(result, config) {


This merge appears to just discard any other options that were specified in the Babel config.

This is a very simple merge, yes. The first config to be passed is the user specified one. The others are all internally generated, and only have plugins and presets, so that shouldn't be a problem.

Fair point. I guess this more goes back to my other comment then. preset-env could at any time start using overrides or env or test/include/exclude, or add other options as top-level flags, and then it would cease to function on Parcel because Parcel is hard-coded to only carry over plugins.

loganfsmyth · 2018-09-16T20:18:02Z

src/transforms/babel/babelrc.js

+    );
+  }
+
+  for (let key of ['extends', 'overrides', 'test', 'include', 'exclude']) {


I think you'll want 'env' in here too.

loganfsmyth · 2018-09-16T20:19:38Z

src/transforms/babel/babel7.js

+  config.configFile = false;
+  config.parserOpts = Object.assign({}, config.parserOpts, {
+    allowReturnOutsideFunction: true,
+    strictMode: false,


Assuming this is to allow parsing both scripts and modules, you'd likely be better off doing sourceType: "unambiguous".

loganfsmyth · 2018-09-16T20:43:50Z

src/transforms/babel/env.js

+  }
+
+  let plugins = presetEnv.default(
+    {assertVersion: () => true},


Could you point me to where you are processing these plugins? I'm having trouble finding it.

Part of my issue here is that the exact return value of a preset is not a public API, because a preset can also have other presets, and what we'd actually need is an API to fully flatten the configuration into a list of plugins, which is pretty much what loadOptions already provides. We wouldn't want to expose makeAPI because it exposes internal implementation details of Babel itself, and it's not obvious what anyone would actually be able to do with the result anyway, other than pass it right back to Babel again unprocessed.

loganfsmyth · 2018-09-16T21:08:27Z

One of the things mentioned as part of the babel 7 upgrade was that all of the plugins and presets now have a peer dependency on the version of @babel/core that they need. This makes it pretty easy for us to auto detect the version of babel that Parcel needs to use. I think babel should enforce this requirement on third party plugins as well.

I actually have very mixed feelings about our addition of peerDependencies and I think it yet to be seem whether they will be good or bad for us. Take even just the Parcel case, if the user installs Babel plugins in the project root and installs @babel/core, there's no guarantee that the version there will be the version that Parcel itself runs, since it might have it's own copy in node_modules/parcel/node_modules/@babel/core, meaning that the Babel version loaded by peerDependencies for the user's plugin would be different from the version that is actually calling Babel. That'd be different if Parcel itself wanted to require users to install @babel/core and itself had a peerDependency on @babel/core, but that's not happening. We've already got static assertions inside our own plugins either way, so in the end I'm not sure the peerDependencies in the plugins actually get us anything.

You're right that JS-based config files are problematic, and I think they are not really a great idea in general. Parcel will support them, but probably not quite as automatically as .babelrc. We cannot help auto install plugins, or detect the version of babel to use automatically in that case. I think if people want to use JS configs, then they are responsible for ensuring that all of their plugins are installed themselves, and that they have a dependency on babel core in their package.json prior to running Parcel.

I understand where you're coming from, but I think for the average user, the expressive abilities of JS configs usually end up outweighing any benefits of configs being static files. If the user's config is representable as static JSON, you'll still get static JSON back from loadPartialConfig, so the benefit of static files is really only being able to process them without calling Babel itself, and I think that's just going to be a losing battle all around.

devongovett · 2018-09-16T23:16:10Z

Parcel never calls user-specified plugins with its internally installed copy of @babel/core. It always uses the locally installed one specified by the app, which hopefully would match the peer dependencies of plugins. If one isn't installed locally in the app, we auto install one for the user. See https://github.com/parcel-bundler/parcel/blob/master/src/transforms/babel/babel7.js#L8-L10.

the expressive abilities of JS configs usually end up outweighing any benefits of configs being static files

I disagree. I'm not sure what people are doing that they feel like they need to write a dynamic config with JS, but it seems like that will just be chaos similar to webpack.config.js, gulpfile.js and other past attempts.

That said, as long as there is a way to call into babel to resolve this JS-based config into a static config, it should be fine for Parcel. We won't be able to help the user with auto installation in that case, but that's fine I think. They already opted into advanced-mode by choosing JS config anyway.

loganfsmyth · 2018-09-16T23:39:22Z

Parcel never calls user-specified plugins with its internally installed copy of @babel/core

That's fair, but it only means that the reverse problem could exist with Parcel's preset-env since Parcel is the one that depends on preset-env, so the peerDependency will be Parcel's version, even though the Babel transform itself is being run by the user's copy. At the end of the day, it may not matter anyway, but I do think the peer dependency just adds to the confusion.

I disagree. I'm not sure what people are doing that they feel like they need to write a dynamic config with JS, but it seems like that will just be chaos similar to webpack.config.js, gulpfile.js and other past attempts.

I'm sure we could talk about it for a while, but I'm not sure it's really worth it. From my standpoint, I don't consider those chaos.

That said, as long as there is a way to call into babel to resolve this JS-based config into a static config, it should be fine for Parcel. We won't be able to help the user with auto installation in that case, but that's fine I think. They already opted into advanced-mode by choosing JS config anyway.

Yup, totally fair.

gaui · 2018-09-17T03:06:31Z

v1.10.0-beta.1 works great - thank you!

juliedavila · 2018-09-17T17:54:28Z

@devongovett hmm for me it seems .babelrc and babel.config.js are completely ignored on v1.10.0-beta.1

gaui · 2018-09-17T23:23:06Z

@defionscode how so?

loganfsmyth · 2018-09-18T00:41:02Z

babel.config.js is definitely ignored at the moment, but .babelrc should work.

simonlc · 2018-09-19T17:36:57Z

I don't understand if .babelrc is fully functional yet, but using the "env" format doesn't work, while .babelrc without it does work.

Doesn't work:

{
  "env": {
    "development": {
      "plugins": [
        "react-hot-loader/babel",
        "@babel/plugin-proposal-class-properties"
      ],
      "presets": [
        "@babel/env",
        "@babel/react"
      ]
    },
    "production": {
      "plugins": [
        ["transform-react-remove-prop-types", {
          "classNameMatchers": ["Component"],
          "removeImport": true
        }],
        "@babel/plugin-proposal-class-properties"
      ],
      "presets": [
        ["@babel/env", {
          "shippedProposals": true
        }],
        "@babel/react"
      ]
    }
  }
}

Works:

{
  "plugins": [
    ["transform-react-remove-prop-types", {
      "classNameMatchers": ["Component"],
      "removeImport": true
    }],
    "@babel/plugin-proposal-class-properties"
  ],
  "presets": [
    ["@babel/env", {
      "shippedProposals": true
    }],
    "@babel/react"
  ]
}

juliedavila · 2018-09-19T17:46:50Z

@gaui @loganfsmyth so in particular, it seems that if you supply exclude config option to a babel preset it doesn't actually exclude any plugins. So something like

      presets: [
        [
          '@babel/preset-env',
          {
            exclude: [
              'transform-classes'
            ]
          }
        ]
      ]

I will note that this is the same behavior in the current stable branch with babel < 7. Excludes are seemingly skipped. You can supply any random string to exclude and it will still build no problem when it really should be throwing a babel-related error IF it were reading that section in.

mririgoyen · 2018-09-25T21:26:19Z

I'm confused on why this was merged and released without full Babel 7 support? You cannot use babel.config.js as they recommend to do so and, as reported above, using "env" is completely broken in both Babel 6 and 7.

WIP: babel 7

3853467

devongovett commented Aug 29, 2018

View reviewed changes

devongovett mentioned this pull request Aug 29, 2018

Babel 7 support #868

Closed

Babel 7: Fix dependency name and upgrade to 7.0.0 (#1956)

e0df562

* Fix babel-types dependency name * Upgrade to Babel 7

DeMoorJasper reviewed Aug 29, 2018

View reviewed changes

DeMoorJasper added 19 commits August 29, 2018 13:08

remove babel6 from pkg.json, update internal babel configs and update…

05c0fb8

… hasConfig to handle arrays to check babel6 and 7

remove async-super-babel-plugin

89d236b

remove babel polyfill test for useBuiltins

4e613c9

remove babel-template requires

106c43d

fix html import tests

71a75dc

fix formatting

dd06677

work around template string bug in Babel 7?

cfad048

format

a1b0f4c

remove matches-pattern

bbf0cd4

get rid of lint issues

04617c4

fix comment

03c88b5

merge

3acd84a

detect babel 6 configs

4af249a

remove babylon 6

b371872

fix getBabelRc

ad78546

babel 7 to babel 6 ast convertor v1

682175c

remove some random code

8bdb5b3

add babel 6 => babel 7 convertor

15a1421

add js tests back in

762cc00

devongovett added 6 commits September 15, 2018 21:37

Fix tests

10934f0

lint + prettier

de1e218

Restore removed test

5e126c5

Add more babel version autoinstall tests

e7468cb

Resolve plugins relative to the correct dir

6a53c00

Test autoinstalling babel plugins

2e3872a

devongovett changed the title ~~WIP: babel 7~~ Babel 7 Sep 16, 2018

Upgrade browserslist

00e4ab0

devongovett merged commit c9c5805 into master Sep 16, 2018

devongovett deleted the babel7 branch September 16, 2018 05:59

loganfsmyth reviewed Sep 16, 2018

View reviewed changes

devongovett mentioned this pull request Sep 25, 2018

[WIP] Babel Autoinstall #1772

Closed

4 tasks

devongovett added a commit that referenced this pull request Oct 15, 2018

Babel 7 (#1955)

4fda5ac

devongovett added a commit that referenced this pull request Oct 15, 2018

Babel 7 (#1955)

6684e8b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Babel 7 #1955

Babel 7 #1955

devongovett commented Aug 29, 2018 •

edited

devongovett Aug 29, 2018

tunnckoCore commented Aug 29, 2018

devongovett commented Aug 29, 2018

hzoo commented Aug 29, 2018

devongovett commented Aug 29, 2018

hzoo commented Aug 29, 2018

tunnckoCore commented Aug 29, 2018 •

edited

DeMoorJasper Aug 29, 2018 •

edited

DeMoorJasper Aug 29, 2018

devongovett commented Sep 16, 2018

tunnckoCore commented Sep 16, 2018

bkniffler commented Sep 16, 2018

loganfsmyth commented Sep 16, 2018

devongovett commented Sep 16, 2018 •

edited

devongovett commented Sep 16, 2018

loganfsmyth Sep 16, 2018

loganfsmyth Sep 16, 2018

devongovett Sep 16, 2018

loganfsmyth Sep 16, 2018

loganfsmyth Sep 16, 2018

loganfsmyth Sep 16, 2018

loganfsmyth Sep 16, 2018

loganfsmyth commented Sep 16, 2018

devongovett commented Sep 16, 2018

loganfsmyth commented Sep 16, 2018

gaui commented Sep 17, 2018

juliedavila commented Sep 17, 2018

gaui commented Sep 17, 2018

loganfsmyth commented Sep 18, 2018

simonlc commented Sep 19, 2018

juliedavila commented Sep 19, 2018

mririgoyen commented Sep 25, 2018


		module.exports = getBabelConfig;

		function mergeConfigs(result, config) {

Babel 7 #1955

Babel 7 #1955

Conversation

devongovett commented Aug 29, 2018 • edited

Choose a reason for hiding this comment

tunnckoCore commented Aug 29, 2018

devongovett commented Aug 29, 2018

hzoo commented Aug 29, 2018

devongovett commented Aug 29, 2018

hzoo commented Aug 29, 2018

tunnckoCore commented Aug 29, 2018 • edited

DeMoorJasper Aug 29, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devongovett commented Sep 16, 2018

tunnckoCore commented Sep 16, 2018

bkniffler commented Sep 16, 2018

loganfsmyth commented Sep 16, 2018

devongovett commented Sep 16, 2018 • edited

devongovett commented Sep 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

loganfsmyth commented Sep 16, 2018

devongovett commented Sep 16, 2018

loganfsmyth commented Sep 16, 2018

gaui commented Sep 17, 2018

juliedavila commented Sep 17, 2018

gaui commented Sep 17, 2018

loganfsmyth commented Sep 18, 2018

simonlc commented Sep 19, 2018

juliedavila commented Sep 19, 2018

mririgoyen commented Sep 25, 2018

devongovett commented Aug 29, 2018 •

edited

tunnckoCore commented Aug 29, 2018 •

edited

DeMoorJasper Aug 29, 2018 •

edited

devongovett commented Sep 16, 2018 •

edited