Prepare codebase for inline Babel 8 breaking changes #12440
Conversation
nicolo-ribaudo
added
PR: Internal 🏠
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/34002/ |
|
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:
|
There was a problem hiding this comment.
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
force-pushed
the
prepare-for-breaking-changes
branch
from
a722b3b to
27307fa
Compare
nicolo-ribaudo
force-pushed
the
prepare-for-breaking-changes
branch
from
27307fa to
1e31f38
Compare
|
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. |
|
This is exciting 🚀 |
github-actions
bot
added
the
outdated
5 participants
The current process for working on Babel 8 features is:
next-8-devbranch, that we target with breaking PRsnext-8-rebasedbranch, 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.maininnext-8-devnext-8-rebasedonmainMerges/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 specifyingSTRIP_BABEL_8_FLAG=true.There are currently 29 commits in
next-8-rebased, and most of them could be moved tomain. 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")
1ee144c69cReplace lodash 'escapeRegExp' with escape-string-regexp library (Replace lodash 'escapeRegExp' with escape-string-regexp library #11842)5ae8ab2579Make automatic runtime the default for JSX compilation (Make automatic runtime the default for JSX compilation #11436)6b3f1fdaf4chore: lint-js-ci depends on build-bundle9ec4ab43d6chore: fix yarn warnings034981d0c3Drop core-js 2 support (Drop core-js 2 support #11751)f50f7aa4feEnable theBABEL_TYPES_8_BREAKINGflag in@babel/types(Enable theBABEL_TYPES_8_BREAKINGflag in@babel/types#11172)5a44a83c51breaking: remove useSpread and useBuiltIns option (breaking: remove useSpread and useBuiltIns option #11141)6b0be825e5add rejects assertion to fixture-test-runner (chore: add rejects assertion to fixture-test-runner #11740)5535630633Better file extension handling for TypeScript and Flow presets (Better file extension handling for TypeScript and Flow presets #11316)f7ab3749a3Update transform-unicode-escapes test to output minimal strings (Update transform-unicode-escapes test to output minimal strings #11721)ee5d2ed479Remove backward compatibility for union types (Remove backward compatibility for union types #11468)1727d26062Improve syntax highlighting (Improve syntax highlighting #11413)cb4917510eDisable e2e-babel-old-version test (Disable e2e-babel-old-version test #11477)8406b10005Update failing test on Windows (Update failing test on Windows #11454)d9c65dbe6bOutput minimal strings by default (Output minimal strings by default #11384)cd0c303894Remove error plugin name mappings of removed parser plugins (chore: remove error plugin name mappings of enabled parser plugin #11234)e1f91da012Remove config hack for old Node compatibility (Remove config hack for old Node compatibility #11199)cd41cc9165Remove jsonCompatibleStrings option (Remove jsonCompatibleStrings option #9958)0881dd8629Use require.resolve instead of the "resolve" package (Use require.resolve instead of the "resolve" package #11125) (:warning: Backported in Userequire.resolveinstead of theresolvepackage #12439)7217f71c57Remove the allowDeclareFields TS option and make it the default behavior (Remove the allowDeclareFields TS option and make it the default behavior #11114)635c7fd6a9Avoid removing uninitialized class fields with flow (Avoid removing class fields using flow inplugin-transform-flow-strip-typesplugin #10120)2eeb3497b0Bump dependencies (Bump Node support to >= 10.13 #10747)5e4757c3e7Remove polyfills and minNodeVersion for old Node.js (Bump Node support to >= 10.13 #10747)ef1edc1416Drop Node.js <10.13 support (Bump Node support to >= 10.13 #10747)94431e4dafRemoveuglifytarget support in preset-env (Removeuglifytarget support in preset-env #10895)13fa535e59Remove functions present only for backwards-compatibility (Remove functions present only for backwards-compatibility (#6993) #11095)129149ed4cbreaking: remove parserOpts.objectRestSpread from typescript (breaking: remove parserOpts.objectRestSpread from typescript #10915)524080265efeat(babel-parser): throw syntax error for}and>in JSX… (feat(babel-parser): throw syntax error for}and>in JSX text #11046)3b1404991fjsx: 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.jsonfiles.When we'll release a Babel 8 alpha/beta/RC, we will have to:
mainBABEL_8_BREAKING=trueThis 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-rebasedtomain: nicolo-ribaudo/babel@prepare-for-breaking-changes...nicolo-ribaudo:breaking/disallow-sequence-expression-in-jsxWhat do you think about this approach?