search

babel / babel

🐠 Babel is a compiler for writing next generation JavaScript.
https://babel.dev
MIT License
42.99k stars 5.59k forks source link

Babel 8 Release Plan #10746

Open nicolo-ribaudo opened 4 years ago

nicolo-ribaudo commented 4 years ago

We plan to release a new major version in 2024 (milestone).

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.

Note for maintainers: release workflow 1. Locally checkout the `main` branch 2. Run `make new-babel-8-version`, which will: - Compute the new prerelease version, by adding 1 to the prerelease number in `package.json#version_babel8` - Update `package.json#version_babel8`, and commit it to `main` - Create a new `release/${version}` branch - Run `yarn release-tool version ${version} --all` in that branch, to update the version of every package to the new pre-release 3. Push `main`, `release/${version}` and the new `v${release}` tag to `babel/babel` Then, the `release` GH workflow will start running on the new tag and publish it to npm.

Related: https://github.com/babel/babel/issues/10752

Note for contributors

~~We implement Babel 8 breaking changes under the BABEL_8_BREAKING env flag. To test the breaking changes, please duplicate the affected tests with the -babel-7 suffix and add BABEL_8_BREAKING: false to test options. The breaking changes will be merged to the main branch but stripped before publishing. ~~

TrejGun commented 4 years ago

Remove ts type imports on Program:exit

will this allow to generate .d.ts files?

nicolo-ribaudo commented 4 years ago

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

fwh1990 commented 4 years ago

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

nicolo-ribaudo commented 4 years ago

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.x.

Andarist commented 4 years ago

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 commented 4 years ago

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

nicolo-ribaudo commented 4 years ago

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

zloirock commented 4 years ago

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 commented 4 years ago

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.

Pranav2612000 commented 4 years ago

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 commented 4 years ago

Another good one could be https://github.com/babel/babel/issues/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 commented 4 years ago

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 commented 4 years ago

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

nicolo-ribaudo commented 4 years ago

For whoever is watching this issue: I just added the Use the new JSX implementation by default section.

nicolo-ribaudo commented 4 years ago

Update: I added the Parse JSX elements when both the JSX and TypeScript plugins are enabled section.

peterjuras commented 4 years ago

Will the babel 8 release also include default handling of .ts and .tsx extensions? (see #8652). It's tagged with the milestone but this issue doesn't mention it.

jridgewell commented 4 years ago

Can we also take the chance to rename now-standard features still listed a proposal-*?

AviVahl commented 4 years ago

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

How would such change be compatible with babel-register? Unless I'm missing something, require.extensions is synchronous.

EDIT: nevermind. just noticed the separate sync versions are kept.

cpojer commented 4 years ago

Hello! Thanks everyone for your hard work on Babel (8). I wanted to ask about your upgrade strategy. To this day, Babel 6 is still found in many dependency trees of projects that use Babel 7 just because some tools haven't been (properly) upgraded. With many tools pulling in Babel 7, what is your recommendation on adopting Babel 8 to avoid mixing Babel 7 and 8 (and 6)?

It seems that due to semver there will be an awkward period of time when some tooling will be updated to use Babel 8 and some won't, likely forcing projects to use both in their projects or hold off on upgrading for a long time altogether.

In the original post it was said that there will be a Babel 7 release with all the non-breaking changes, which is awesome! Is there any consideration to keep the version gap to a minimum? One approach could be further updates to Babel 7 that enable the breaking changes as opt-in configuration options and I'm sure there are others.

nicolo-ribaudo commented 4 years ago

It's not always possible, but in most cases we are making it so that something that works with Babel 8 can also work with Babel 7. Sometimes it works "out of the box" (for example for Disallow using babel.transform, babel.transformFile, babel.transformFromAst, babel.parse, babel.loadOptions and babel.loadPartialConfig synchronously), other times by enabling the corresponding option (for example, Transforms JSX spread properties using object spread).

cpojer commented 4 years ago

Keep in mind the impact of duplicating Babel 6 and Babel 7 was lower because the package names changed from the babel- prefix to using the @babel org. When Babel 8 comes out, it is likely that through hoisting rules every tool will pull in its own copy of Babel 7 or 8 within its sub-node_modules folder.

Babel 6 had a "bridge" mode that allowed installing version 7 of some packages like babel-core bridging to @babel/core.

mohsen1 commented 4 years ago

Please add ts and tsx as default extensions. I spent a few hours to figure out babel-node need specifying extensions for it to work when importing ts files. @peterjuras

kaicataldo commented 4 years ago

I’m beginning to rethink our plan to release the @babel/eslint-* packages with Babel 8. I believe we’re ready to release those packages now - any further necessary changes will become apparent with the myriad of integrations in the community. If we were to release these packages in the next v7 line release, we could start getting immediate feedback. One other possible benefit is that if we need to make any breaking changes we can get them out in the v8 release.

Thoughts?

nicolo-ribaudo commented 4 years ago

The next ESLint release has been in the prerelease state for too long. If it's already compatible with ESLint 7, I would be ok with releasing it in Babel 7.

cpojer commented 4 years ago

Question: could the official upgrade guide suggest how library authors can make their code compatible with both Babel 7 and 8, and then recommend them to use a semver range that works with either 7 or 8 until 7 is dropped at a later time?

I believe that could significantly reduce the gap in time when some tools are upgraded but others aren't.

nicolo-ribaudo commented 4 years ago

Yes!

  1. We will check which Babel 7 plugins in this repository work with @babel/core 8, and relax their semver ranges
  2. The @babel/core API (used by Babel integrations such as Jest, Parcel, the webpack and rollup plugins, etc) will work both with Babel 7 and Babel 8. There is a breaking change (https://github.com/babel/babel/pull/11110), but the alternative already works with Babel 7.
  3. If an open-source plugin author needs help to make their plugin work both with Babel 8 and Babel 7, I am happy to help on Slack (and probably also the rest of the team).
cpojer commented 4 years ago

Thanks for the reply @nicolo-ribaudo, that's really exciting as that will ease the transition 👍

hzoo commented 4 years ago

Was thinking through some ideas on how to make the migration easier (not for 1 project for the ecosystem) with @nicolo-ribaudo and @existentialism and I'll post an idea we had here: https://hackmd.io/lAEuzTXzQl6fAir01YgfkQ. (this is in addition to writing up a guide to migrate and codemods where possible)

Basically was thinking we could enable the breaking changes in a 7.x patch under an environmental flag, run like BABEL_8_BREAKING babel or with whatever integration so that any library/plugin can opt-into trying that locally and publish new versions ahead of us releasing anything. We would have to manage the if branches in the code and even tests + cleanup after but maybe that can help ease?

Other ideas welcome.

cpojer commented 4 years ago

@hzoo I think that's a great idea, thank you for thinking about this.

Airkro commented 4 years ago

How about drop support for core-js 3 (in preset-env). We have babel-plugin-polyfill-corejs3 now.

nicolo-ribaudo commented 4 years ago

That was one of my goals when I started working on the polyfill packages, but we should first do https://github.com/babel/rfcs/pull/2

xiaoxiangmoe commented 3 years ago

When will babel 8 release?

TrySound commented 3 years ago

Hi, I found cases like <> ></> are not errors in flow. Could you please clarify if it's also forbidden? https://flow.org/try/#0JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQNwBQduEAdqvAMImTNbPwC8cABQBKOPwB8cAN504cSjACuUZnAA8UieoD0EugF8gA This lint errors fails there https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/no-unescaped-entities.md

nicolo-ribaudo commented 3 years ago

@TrySound It is: you can check JSXTextCharacter at https://facebook.github.io/jsx/.

fabis94 commented 3 years ago

Would be nice to know when we can expect Babel 8. The OP says that it'll come out in 2020, but the year is soon coming to a close and there's no news yet.

WillBeebe commented 3 years ago

Who else is pumped for the chokidar dependency bump? :D

nicolo-ribaudo commented 3 years ago

@fabis94 Sorry for the lack of communication about a precise schedule. My hope is to release Babel 8 alongside with 7.13 (so in about 2 months), since there isn't much left to do. However, please don't take this as an hard deadline since anything could happen :pray:

@WillBeebe Starting from Babel 7.12.0, it will use chokidar@3 if you are using a modern Node.js version :wink: https://github.com/babel/babel/pull/11560

fabis94 commented 3 years ago

Any updates regarding this?

nicolo-ribaudo commented 3 years ago

Yes! We wanted to work on this in a separate branch next-8-dev/next-8-rebased, but we found out that it was really slowing us down. We are now starting to add these Babel 8 changes to main, so that it's easier for us to work on them and hopefully will help us finish this release in a reasonable time.

jridgewell commented 3 years ago

One more thing that's always bugged me: we should rename OVERWRITE to TEST_OVERWRITE. It doesn't make sense to use make test-only TEST_ONLY=class-properties TEST_GREP=public OVERWRITE=true

nicolo-ribaudo commented 3 years ago

No need to wait for Babel 8, we can add an alias now.

rinarakaki commented 2 years ago

Would you mind updating the current progress of the task list? Some of them seem to have already been solved.

Ontopic commented 2 years ago

Yes! We wanted to work on this in a separate branch next-8-dev/next-8-rebased, but we found out that it was really slowing us down. We are now starting to add these Babel 8 changes to main, so that it's easier for us to work on them and hopefully will help us finish this release in a reasonable time.

So in order to play around with where things are at, will a @next or ^7.15 bring me the closest?

JLHwung commented 2 years ago

So in order to play around with where things are at, will a @next or ^7.15 bring me the closest?

7.15 has been published but it will not contain Babel 8 breaking changes, as required by semver. We don't have Babel 8 nightly build, but we have Babel 8 e2e test on popular libraries: https://github.com/babel/babel/blob/614b48678095746b83bbe517c4d6b30ba8cd5c04/.circleci/config.yml#L131 you can fork Babel repo and run e2e test on your own library to see if Babel 8 will break. Feedbacks are always welcome.

Ontopic commented 2 years ago

Thanks! Long time since I last build Babel myself. Let's see the dev contributor experience nowadays :)

Semigradsky commented 2 years ago

Bump Node Support to >=12.19

Should it be updated to >=14? 12's EOL is 2022-04-30.

nicolo-ribaudo commented 2 years ago

Yes thanks, we are a few years late with this release! :upside_down_face:

(If it takes another year we can also drop Node.js 14 :eyes:)

dlong500 commented 1 year ago

I hate to be that guy, and I know that ultimately a release is ready when it's ready, but given the timeframe here can we get an update on where things stand? The Babel Roadmap page hasn't been updated since 2021 (at which point there was a note about how long it had already been taking and how the release was "closer than ever").

Nantris commented 1 year ago

Friendly bump on the question above.

csvan commented 1 year ago

Hate to state the obvious, but the best thing you can do to help issues like this is getting your employer - or yourself - to sponsor and otherwise contribute to open source.

Many crucial open source projects - such as Babel - are developed by volunteers in their spare time, while large corporations and startups alike incorporate them into their commercial products without ever giving anything back. I am actively working in my organisation to get that changed, and I hope others will too.