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 · 5 comments
Open

Babel 8 Release Plan #10746

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

Comments

@nicolo-ribaudo
Copy link
Member

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

We plan to release a new major version in the beginning of 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)
      • 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 }]
          ]
        }
    • 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.
    • 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
    • Transforms JSX spread properties using object spread
      • 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.
  • API breaking changes

  • 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).
  • 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

@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"
    }
  }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.