Prepare codebase for inline Babel 8 breaking changes

[nicolo-ribaudo]

Q	A
Tests Added + Pass?	Yes
License	MIT

The current process for working on Babel 8 features is:

• We have a next-8-dev branch, that we target with breaking PRs
• We have a next-8-rebased branch, which is a "clean" branch for Babel 8. We can rewrite the history of this branch when we need to remove a commit because it's not needed anymore after a change in Babel 7.
• We regularly merge main in next-8-dev
• We regularly rebase next-8-rebased on main

Merges/rebases often take a lot of time (a few hours at least), especially when there is a big number of merge conflicts. Also, the risk of introducing bugs is high (as an example, both the branches for Babel 8 are failing on CI).

With this PR, it would be possible to inline many breaking changes (everything except for dependency updates) directly in main, stripping them at build time when publishing by specifying STRIP_BABEL_8_FLAG=true.

There are currently 29 commits in next-8-rebased, and most of them could be moved to main. What can't be moved are mostly depenencies updates

(:x: = "cannot be moved", :heavy_check_mark: = "can be moved", :grey_question: = "needs investigation"/"not applicable")

• ❌ 1ee144c69c Replace lodash 'escapeRegExp' with escape-string-regexp library (Replace lodash 'escapeRegExp' with escape-string-regexp library #11842)
• ✔️ 5ae8ab2579 Make automatic runtime the default for JSX compilation (Make automatic runtime the default for JSX compilation #11436)
• ❔ 6b3f1fdaf4 chore: lint-js-ci depends on build-bundle
• ❔ 9ec4ab43d6 chore: fix yarn warnings
• ✔️ 034981d0c3 Drop core-js 2 support (Drop core-js 2 support #11751)
• ✔️ f50f7aa4fe Enable the BABEL_TYPES_8_BREAKING flag in @babel/types (Enable the BABEL_TYPES_8_BREAKING flag in @babel/types #11172)
• ✔️ 5a44a83c51 breaking: remove useSpread and useBuiltIns option (breaking: remove useSpread and useBuiltIns option #11141)
• ✔️ 6b0be825e5 add rejects assertion to fixture-test-runner (chore: add rejects assertion to fixture-test-runner #11740)
• ✔️ 5535630633 Better file extension handling for TypeScript and Flow presets (Better file extension handling for TypeScript and Flow presets #11316)
• ❔ f7ab3749a3 Update transform-unicode-escapes test to output minimal strings (Update transform-unicode-escapes test to output minimal strings #11721)
• ✔️ ee5d2ed479 Remove backward compatibility for union types (Remove backward compatibility for union types #11468)
• ✔️/❌1727d26062 Improve syntax highlighting (Improve syntax highlighting #11413)
• ❔ cb4917510e Disable e2e-babel-old-version test (Disable e2e-babel-old-version test #11477)
• ❔ 8406b10005 Update failing test on Windows (Update failing test on Windows #11454)
• ✔️ d9c65dbe6b Output minimal strings by default (Output minimal strings by default #11384)
• ✔️ cd0c303894 Remove error plugin name mappings of removed parser plugins (chore: remove error plugin name mappings of enabled parser plugin #11234)
• ❔ e1f91da012 Remove config hack for old Node compatibility (Remove config hack for old Node compatibility #11199)
• ✔️ cd41cc9165 Remove jsonCompatibleStrings option (Remove jsonCompatibleStrings option #9958)
• ❔ 0881dd8629 Use require.resolve instead of the "resolve" package (Use require.resolve instead of the "resolve" package #11125) (:warning: Backported in Use require.resolve instead of the resolve package #12439)
• ✔️ 7217f71c57 Remove the allowDeclareFields TS option and make it the default behavior (Remove the allowDeclareFields TS option and make it the default behavior #11114)
• ✔️ 635c7fd6a9 Avoid removing uninitialized class fields with flow (Avoid removing class fields using flow in plugin-transform-flow-strip-types plugin #10120)
• ❌ 2eeb3497b0 Bump dependencies (Bump Node support to >= 10.13 #10747)
• ❌ 5e4757c3e7 Remove polyfills and minNodeVersion for old Node.js (Bump Node support to >= 10.13 #10747)
• ❌ ef1edc1416 Drop Node.js <10.13 support (Bump Node support to >= 10.13 #10747)
• ✔️ 94431e4daf Remove uglify target support in preset-env (Remove uglify target support in preset-env #10895)
• ✔️ 13fa535e59 Remove functions present only for backwards-compatibility (Remove functions present only for backwards-compatibility (#6993) #11095)
• ✔️ 129149ed4c breaking: remove parserOpts.objectRestSpread from typescript (breaking: remove parserOpts.objectRestSpread from typescript #10915)
• ✔️ 524080265e feat(babel-parser): throw syntax error for } and > in JSX… (feat(babel-parser): throw syntax error for } and > in JSX text #11046)
• ✔️ 3b1404991f jsx: fix sequence expression at JSXAttributeValue (jsx: fix sequence expression at JSXAttributeValue #8787)

We would still need a separate branch for dependency updates, but it would be way easier to merge/rebase since the changes would be mostly isolated in package.json files.

When we'll release a Babel 8 alpha/beta/RC, we will have to:

• Create a new branch from main
• Apply the "dependency update" commits on top of it
• Release with BABEL_8_BREAKING=true

This PR also introduces a new flag in our fixutres options, BABEL_8_BREAKING: boolean, and when it is specified the test is only run if Babel has been built with the corresponding breaking changes.

This is an example of a backport from next-8-rebased to main: nicolo-ribaudo/babel@prepare-for-breaking-changes...nicolo-ribaudo:breaking/disallow-sequence-expression-in-jsx

What do you think about this approach?

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/34002/

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1e31f38:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[hzoo]

I think it's hard to think of an alternative I guess (and we wanted to do this with the API for endusers anyway). I think generally sounds good? We'll see 😄 . Rebasing certainly takes a long time (as you have mentioned personally) and prone to it's own errors. I guess if applying dependencies isn't that bad (and hopefully there shouldn't be that many) it seems like a good way to keep up.

Maybe best that we don't rely on this, as a temporary measure turns into more (at least we don't plan to do multiple boolean flags, just in this case), or we reduce the amount of time that we need this since we don't plan on multiple lines of development for longer than necessary. I think in this case we want to introduce the features in a minor (say moving preset-env targets to core) and only have the major be default switches/toggles so that it's simple.

[nicolo-ribaudo]

Yeah I agree that this is a one-time thing: I don't want to introduce multiple compilation flags, and we should only do this when it has significant benefits.

[nicolo-ribaudo]

This is exciting 🚀