-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Babel 8 misc changes #15068
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 misc changes #15068
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/54241/ |
16fd76f to
eb7eed7
Compare
| node-version: "14.17" # Node.js 14.17 is the first LTS supported by Babel 8 | ||
| node-version: latest | ||
| check-latest: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried this will cause some issues to go undetected.
Not related to this PR: Do we have a minimum node version requirement for the repository (build and development)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a minimum node version requirement for the repository (build and development)
Currently no. Personally I build / develop on latest Node and upgrade my environment every week. I believe using latest node is important:
- If any node update breaks our build pipeline, we can always fallback to an older version temporarily. (IIRC in the past this scenario only happened in major upgrade)
- Pinning node version will deprive us the benefit of latest build tools, e.g. Jest / Yarn will drop unmaintained node versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I also currently always keep the latest major version.
| module.exports = require("./data/native-modules.json"); | ||
| module.exports = process.env.BABEL_8_BREAKING | ||
| ? require("./data/native-modules-next.json") | ||
| : require("./data/native-modules.json"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag here will ship to end users because we didn't run Babel on these CJS proxies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do this using rollup?
| - name: Extract artifacts | ||
| run: tar -xf babel-artifact.tar; rm babel-artifact.tar | ||
| - name: Generate runtime helpers | ||
| run: make build-plugin-transform-runtime-dist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change should have been included in #15165.
e0896ba to
2f6ca5d
Compare
|
Lines 125 to 128 in 5f19f62
I seem to have had this problem. Because it will use the current node version of the build. |
657c59e to
e29b216
Compare
| make -j build-standalone-ci | ||
| env: | ||
| BABEL_ENV: test | ||
| BABEL_ENV: test-legacy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test-legacy was introduced when we upgraded to Jest 25 which dropped Node.js 6. So we build on latest Node but targeted to a legacy Node version. However, in the Babel 8 situation, Node.js 14 is not a legacy version but a minimum supported one.
Maybe we can merge test-legacy with test, and then we differentiate node target by the CI environment variable. So that if a contributor runs yarn jest, he/she is testing against a build targeted to latest Node, which almost involves no transforms. If CI runs yarn jest, it is testing against the production build.
e29b216 to
4b1c812
Compare
|
@nicolo-ribaudo Thanks for rebasing! |
nicolo-ribaudo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two comments are about the same topic, and if you want I can work on them (since I have a fresh copy of this branch, just rebased)
| newData = defineLegacyPluginAliases(newData); | ||
| if (!process.env.BABEL_8_BREAKING) { | ||
| newData = defineLegacyPluginAliases(newData); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dislike how this causes us to ship both Babel 7 and Babel 8 data to our users, as well as we then need to keep the flag in the CJS proxies (like packages/babel-compat-data/plugin-bugfixes.js)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I think it is fine to keep -next.json in the git repo but we can skip them during publish. As for Babel 8 resolving, maybe we can add yarn condition on the exports of @babel/compa-data and redirect ./plugins.json to ./plugins-next.json.
| const currentData = fs.readFileSync(dataPath, "utf8"); | ||
|
|
||
| // Compare as JSON strings to also check keys ordering | ||
| if (currentData !== stringified) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the Babel 7 data is a superset of the Babel 8 data (thus the Babel 8 build would also work with the Babel 7 data), can we instead only generate the Babel 8 file when process.env.BABEL_8_BREAKING && process.env.IS_PUBLISH, and skip this check in that case?
| @@ -0,0 +1 @@ | |||
| EXECUTOR TIMEOUT | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be removed.
(For some reasons this test keeps failing on my local environment and I must accidentally checkout them out)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also keeps failing on my local environment, it's possible I checked it out while rebasing. I spent one hours trying to understand what was wrong with my local env, I'm "happy" that it's not just me 😅
|
@nicolo-ribaudo Thank you! Yeah you can work on this branch and feel free to overhaul anything. |
c9d994c to
3775e19
Compare
|
#15473 is necessary to fix the |
13291ff to
f40d58b
Compare
f40d58b to
2e02553
Compare
This PR should be reviewed by commits. It cleanups some Babel 8 todo comments. This PR also unifies current slightly different Babel 8 todo comments to
TODO(Babel 8).