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

Babel 8 Release Plan #10746

Open
nicolo-ribaudo opened this issue Nov 21, 2019 · 13 comments
Open

Babel 8 Release Plan #10746

nicolo-ribaudo opened this issue Nov 21, 2019 · 13 comments
Milestone

Comments

@nicolo-ribaudo
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Nov 21, 2019

We plan to release a new major version at the beginning of March 2020.

This release won't have all the migration pain which there was while migrating from Babel 5 to Babel 6 and then from Babel 6 to Babel 7. We plan to only make a few breaking changes, and provide an easy migration strategy for each of them. Because of this, you won't see ~80 prereleases like we did in for Babel 7.0.0, but we plan to only release a few of them.

Babel 8.0.0 will only contain breaking changes: we will release a minor version the same day, containing all the bug fixes and new features that would otherwise be released in 8.0.0.

This document is still a work in progress, but you can already start by applying the suggested migration strategies to your own codebase.

  • Compilation breaking changes

    • Don't remove uninitialized class fields when using Flow/TS (pr for flow: #10120, pr for TS: #11114)
      • Area: Flow and TypeScript transforms

      • Impact: High (only for flow and TypeScript users)

      • Migration:
        Flow users can already update their code to use the flow comments syntax if they don't want to initialized to undefined. This is officially recommended by the Flow team:

        class A {
          foo: ?string; // initialized to undefined
          /*:: bar: number */ // type-only
        }

        TypeScript users can use the new declare syntax, which introduced in TypeScript 3.7 and Babel 7.7:

        class A {
          foo: string | void; // initialized to undefined
          declare bar: number; // type-only
        }

        Note that while this syntax is enabled by default in @babel/parser when using the typescript plugin, if you are using @babel/plugin-transform-typescript or @babel/preset-typescript you must enable the declareFields option:

        {
          presets: [
            ["@babel/typescript", { "declareFields": true }]
          ]
        }
    • Disallow sequence expressions inside JSX attributes (pr: #8787)
      • Area: JSX, @babel/parser
      • Impact: Low
      • Migration: If you are using them, you can already wrap them in parentheses:
        <div key={foo, bar}></div> // Invalid
        <div key={(foo, bar)}></div> // Valid
    • Disallow } and > in JSX text (pr: #11046)
      • Area: @babel/parser with JSX
      • Impact: Low
      • Migration: You can use {'}'} and {'>'} instead.
      • Notes: This is technically a bug fix becase the specification already forbids them. However, we have chosen to postpone it until Babel 8 because it could break someone's code.
    • Transforms JSX spread properties using object spread (pr: #11141)
      • Area: JSX
      • Impact: Medium
      • Migration: You can already have this behavior by using the useSpread option in Babel 7.7.0. If your code needs to run in an environment which doesn't support object spread, you can either use @babel/preset-env (recommended) or @babel/plugin-proposal-object-rest-spread. If you want to transpile Object.assign down to Babel's _extends helper (which is the current default behavior) you also need to enable @babel/plugin-transform-object-assign.
    • Move root AMD/UMD/SystemJS options to be plugin/preset options
      • Area: @babel/core, @babel/cli, @babel/plugin-transform-modules-amd, @babel/plugin-transform-modules-umd, @babel/plugin-transform-modules-systemjs
      • Impact: Medium
      • Migration: When upgrading to Babel 8, you'll move to modify your config and pass these options to the correct plugin or preset.
        If you are passing these options using the cli, you'll need to create a configuration file.
  • Configuration breaking changes

    • Require @babel/plugin-proposal-dynamic-import when transforming import() to SystemJS
      • Area: @babel/plugin-transform-modules-systemjs
      • Impact: Medium
      • Migration: Add @babel/plugin-proposal-dynamic-import to your config: you can already do it in Babel 7. If you are using @babel/preset-env, you don't need to do anything.
      • Notes: All the other plugins which support dynamic import (transform-modules-commonjs and transform-modules-amd) require the separate plugin since it was introduced. We couldn't change it for transform-modules-systemjs because that package did already support dynamic import.
    • Only change browserslist defaults if no config file exists (pr: #10897 )
      • Area: @babel/preset-env
      • Impact: Low
      • Migration: If you are already using targets or have a .browserslist config file, this change won't affect you. Otherwise, you'll probably be fine with the new behavior (which supports these browsers). If you still need to enable every possible plugin, you can already enable the forceAllTransforms option.
    • Remove uglify target (pr: #10895)
      • Area: @babel/preset-env
      • Impact: Low
      • Migration: The uglifyjs target had been deprecated since 7.0.0-beta.0, if you still need this, you can enable the forceAllTransforms option.
    • Drop support for core-js 2 (#10746 (comment))
      • Area: @babel/preset-env, @babel/plugin-transform-runtime
      • Impact: High
      • Migration: You can already change your config to use core-js@3. Don't forget to npm install it!
    • Add mandatory version option to the decorators plugins, and merge the two plugins in @babel/parser.
  • API breaking changes

    • Bump Node Support to >=10.13 (pr: #10747)
      • Area: Every package
      • Impact: Medium
      • Notes: The 8.x Maintenance LTS cycle is currently scheduled to expire early on December 31, 2019 to align with the scheduled End-of-Life of OpenSSL-1.0.2. 10.13 is the first Node.js 10.x LTS version.
      • TODO: Upgrade to Yarn 2
    • Disallow using babel.transform, babel.transformFile, babel.transformFromAst, babel.parse, babel.loadOptions and babel.loadPartialConfig synchronously (pr: #11110)
      • Area: @babel/core
      • Impact: Medium
      • Migration: You can use babel.transformSync, babel.transformFromAstSync and babel.transformFileSync, supported since version 7.0.0. babel.parseSync, babel.loadOptionsSync and babel.loadPartialConfigSync will be introduced in v7.8.0.
    • Don't generate TSParenthesizedType unless createParenthesizedExpression is enabled
      • Area: @babel/parser
      • Impact: Low
      • Migration: If you need informations about parentheses, you can already enable the createParenthesizedExpression parser option (supported since Babel 7.4.0)
    • Remove t.jSX* and t.tS* builder aliases (pr: #6993)
      • Area: @babel/types
      • Impact: Low
      • Migration: Use t.jsx* and t.ts* instead, which have been supported since Babel 7.0.0
    • Reject invalid identifiers in t.identifier builder (pr was reverted)
      • Area: @babel/types
      • Impact: Medium
      • Notes: Breaks metro bundler as of Nov 2019 (#10645)
    • Remove jsonCompatibleStrings generator option (pr: #9958)
      • Area: @babel/generator
      • Impact: Medium
      • Migration: @babel/generator allows to specify options for jsesc, the library used to escape printed values.
        If you are using the jsonCompatibleStrings option, you can replace it with jsescOption: { json: true }.
    • Disallow useBuiltIns: 0 when transforming JSX (pr: #10927)
      • Area: @babel/plugin-transform-react-jsx, @babel/preset-env
      • Impact: Low
      • Migration: Use useBuiltIns: false instead.
  • Misc breaking changes

    • Bump peer dependency on @babel/core to ^8.0.0
      • Area: Every package
      • Impact: None if you update every @babel/* package
    • ESM runtime helper files should have the .mjs extension
      • Area: @babel/runtime, @babel/runtime-corejs2, @babel/runtime-corejs3
      • Impact: Medium
      • Notes: ES Modules are now unflagged (nodejs/node#29866), and .js modules don't work with native import unless our package.json specifies type: "module" (which will break cjs helpers).
    • Change the format of CommonJS helpers in @babel/runtime
      • Area: @babel/runtime, @babel/runtime-corejs2, @babel/runtime-corejs3
      • Impact: Low
      • Notes: This will only affect you if you are using @babel/runtime 7.x with @babel/plugin-transform-runtime 8.x (or the other way around), which woudln't be supported anyway.
    • Disallow importing internal files of the different packages (pr: #10850)
      • Area: Every package
      • Impact: High
      • Notes: This will break at least vue-cli (cc @sodatea) and ember-cli-babel [2] (cc @rwjblue). We will provide targets-parser as a separate helper in v7.8.0.
        ⚠️ If anyone else is relying on internal Babel files, please let us know!
  • Other possibly breaking changes

    • Remove ts type imports on Program:exit (pr: #10009)
      • Area: @babel/plugin-transform-typescript
      • Impact: Low
    • Allow skipped NodePaths to be requeued
      • Area: @babel/traverse
      • Impact: Low
      • Notes: This is actually a bugfix, but it causes an infinite loop in the tdz implementation of @babel/plugin-transform-block-scoping
    • Look for comments containing "Babel 8" in the source code
      • Area: Every package
      • Impact: Low
      • Notes: Most of those comments are just for internal dependencies between packages. Any significant change will have a dedicated point in this list of breaking changes.

Related: #10752


Note for contributors

We are currently developing Babel 8 in the next-8-dev branch. We will periodically merge master in next-8-dev.
We are also maintaining a separate branch, next-8-rebased to clearly show the commits specifically related to Babel 8.
PRs for Babel 8 should be opened to the next-8-dev branch.

@nicolo-ribaudo nicolo-ribaudo added this to the Babel 8.x milestone Nov 21, 2019
@JLHwung JLHwung pinned this issue Nov 21, 2019
@TrejGun

This comment has been minimized.

Copy link

@TrejGun TrejGun commented Nov 22, 2019

Remove ts type imports on Program:exit

will this allow to generate .d.ts files?

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member Author

@nicolo-ribaudo nicolo-ribaudo commented Nov 29, 2019

@TrejGun It is totally unrelated I think. I'd be happy to hear more about it on our Slack!

@fwh1990

This comment has been minimized.

Copy link

@fwh1990 fwh1990 commented Dec 2, 2019

Will 8.x be faster than 7.x when building my own project?

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member Author

@nicolo-ribaudo nicolo-ribaudo commented Dec 2, 2019

No. Version 8.0 will only contain breaking changes, so if there are any performance improvements that we can make they will also be included in 7.8.0.

@Andarist

This comment has been minimized.

Copy link
Member

@Andarist Andarist commented Dec 4, 2019

I would like to propose a breaking change.

I believe that @babel/runtime helpers should not get special treatment when transpiled to CJS - at least not for their export shape (used requires etc can still be optimized). I propose such output:

+"use strict";
+exports.__esModule = true;
+exports.default = _toPropertyKey;

-var _typeof = require("../helpers/typeof");
+var _typeof = require("../helpers/typeof").default;

-var toPrimitive = require("./toPrimitive");
+var toPrimitive = require("./toPrimitive").default;

function _toPropertyKey(arg) {
  var key = toPrimitive(arg, "string");
  return _typeof(key) === "symbol" ? key : String(key);
}

-module.exports = _toPropertyKey;

With such ESM-compatible output we could try to explore removing useESModules option from @babel/plugin-transform-runtime because it's possible to create a "proxy" package.json that would allow bundlers & node to pick up the correct version of a particular helper on their own using a single path (that would be inserted by transform runtime). The directory structure could look smth like this

helpers/toPropertyKey/package.json
helpers/toPropertyKey/toPropertyKey.js
helpers/toPropertyKey/toPropertyKey.mjs

with package.json being:

{
  "name": "@babel/runtime/helpers/toPropertyKey",
  "private": true,
  "type": "module",
  "main": "./toPropertyKey.cjs.js",
  "module": "./toPropertyKey.js",
  "exports": {
    ".": {
      "require": "./toPropertyKey.cjs.js",
      "default": "./toPropertyKey.js"
    }
  }
}
@XaveScor

This comment has been minimized.

Copy link

@XaveScor XaveScor commented Jan 12, 2020

@babel/preset-env using core-js@2 by default. Can @bable/preset-env@8 using core-js@3 only?

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member Author

@nicolo-ribaudo nicolo-ribaudo commented Jan 12, 2020

Yeah, this is a good idea!
@zloirock WDYT about dropping support for core-js@2?

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Jan 12, 2020

Yes, core-js@2 support should be dropped and the version of core-js should be required argument with useBuiltIns in preset-env. Maybe it could be good also to enforce specifying of minor core-js version.

@zloirock

This comment has been minimized.

Copy link
Member

@zloirock zloirock commented Jan 12, 2020

Why it should be dropped - copy-paste from the draft of one post:

core-js@3 was published 10 months ago - I hoped that this is enough to update. However, core-js@2 still is used more often than core-js@3 - if some dependencies depend on core-js@2, users don't wanna have some copies of core-js in the bundle. However, we should kill core-js@2 ASAP. The main reason is even not some bugs, it's... V8 (de)optimizations - even if nothing is polyfilled. WTF? Now, if V8 saw the usage of some non-often used features (like @@species pattern), for example, in the features detection - V8 always will use the non-optimized version of a method that theoretically could use it. In core-js@2, that affects regexes, iterators, some array methods, typed arrays, promises, etc... Sometimes that causes ~100x performance degradation, let's say thanks to V8. At this moment, V8 is the most popular JS engine, so it's a complex of critical issues. Workarounds for a big part of those deoptimizations were added in core-js@3.0, for remaining - at the latest patch releases. I don't see any reason to spent many days fixing those (and other) issues in the obsolete version.

sodatea added a commit to sodatea/vue-cli that referenced this issue Feb 3, 2020
As planned in babel/babel#10746,
in babel 8 the old `loadPartialConfig` can't be used synchronously.
sodatea added a commit to sodatea/vue-cli that referenced this issue Feb 3, 2020
sodatea added a commit to vuejs/vue-cli that referenced this issue Feb 3, 2020
…abel 8 (#5133)

* refactor: use babel.loadPartialConfigSync (added in babel 7.8)

As planned in babel/babel#10746,
in babel 8 the old `loadPartialConfig` can't be used synchronously.

* refactor: remove dependence on internal babel files, preparing for babel 8

See
babel/babel#10746
babel/babel#10899
sebinsua added a commit to sebinsua/perspective that referenced this issue Feb 5, 2020
We should upgrade core-js@2 to core-js@3 because
the (1) the next major release of Babel will do so,
and (2) there are many V8 de-optimizations in core-js@2
that have been fixed in core-js@3.

See: babel/babel#10746 (comment)
See: babel/babel#10746 (comment)
See: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md
sebinsua added a commit to sebinsua/perspective that referenced this issue Feb 5, 2020
We should upgrade core-js@2 to core-js@3 because
the (1) the next major release of Babel will do so,
and (2) there are many V8 de-optimizations in core-js@2
that have been fixed in core-js@3.

See: babel/babel#10746 (comment)
See: babel/babel#10746 (comment)
See: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md

We also bumped Babel to 7.8.4 because it was only after 7.4 that
core-js@3 was supported.

See: https://babeljs.io/blog/2019/03/19/7.4.0#core-js-3-7646-https-githubcom-babel-babel-pull-7646
sebinsua added a commit to sebinsua/perspective that referenced this issue Feb 5, 2020
We should upgrade core-js@2 to core-js@3 because the (1) the next major
release of Babel will do so, and (2) there are many V8 de-optimizations
in core-js@2 that have been fixed in core-js@3.

See: babel/babel#10746 (comment)
See: babel/babel#10746 (comment)
See: https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md

We also bumped Babel to 7.8.4 because it was only after 7.4 that
core-js@3 was supported.

See: https://babeljs.io/blog/2019/03/19/7.4.0#core-js-3-7646-https-githubcom-babel-babel-pull-7646
@Pranav2612000

This comment has been minimized.

Copy link

@Pranav2612000 Pranav2612000 commented Feb 6, 2020

Hey. I would love to contribute to Babel 8. What are some easy features I can work on? I think I can work on :-

Look for comments containing "Babel 8" in the source code
Area: Every package
Impact: Low
Notes: Most of those comments are just for internal dependencies between packages. Any significant change will have a dedicated point in this list of breaking changes.

Are there any other issues I can contribute to and help?

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member Author

@nicolo-ribaudo nicolo-ribaudo commented Feb 6, 2020

Another good one could be #9546, which would give you the chance to dig into @babel/parser's internals.
Or maybe Disallow using babel.transform, babel.transformFile, babel.transformFromAst, babel.parse, babel.loadOptions and babel.loadPartialConfig synchronously, which is probably a bit easier.
If you prefer, Transforms JSX spread properties using object spread involves removing the useSpread option and making it the default behavior.

If you want to work on the TODOs left in the comments containing "Babel 8", please don't resolve all of them in a single PR but keep separate changes in different PRs.

@Pranav2612000

This comment has been minimized.

Copy link

@Pranav2612000 Pranav2612000 commented Feb 8, 2020

Disallow using babel.transform, babel.transformFile, babel.transformFromAst, babel.parse, babel.loadOptions and babel.loadPartialConfig synchronously
Area: @babel/core
Impact: Medium
Migration: You can use babel.transformSync, babel.transformFromAstSync and babel.transformFileSync, supported since version 7.0.0. babel.parseSync, babel.loadOptionsSync and babel.loadPartialConfigSync will be introduced in v7.8.0.

Shoud I just delete the given functions? Or am I misunderstanding the requirements?

@nicolo-ribaudo

This comment has been minimized.

Copy link
Member Author

@nicolo-ribaudo nicolo-ribaudo commented Feb 8, 2020

Currently they behave asynchronously if you pass them a callback, otherwise they behave synchronously. Only the callback-based version should be allowed.

mactanxin added a commit to mactanxin/vue-cli that referenced this issue Feb 11, 2020
…abel 8 (vuejs#5133)

* refactor: use babel.loadPartialConfigSync (added in babel 7.8)

As planned in babel/babel#10746,
in babel 8 the old `loadPartialConfig` can't be used synchronously.

* refactor: remove dependence on internal babel files, preparing for babel 8

See
babel/babel#10746
babel/babel#10899
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.