-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Implement support for internal @babel/core plugins #14966
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
base: main
Are you sure you want to change the base?
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/53739/ |
51bc1b1 to
c19dc31
Compare
|
This is ready for review. This change isn't much useful per se, because we cannot really move the plugins currently used by
While reviewing, please take a look at the comments in |
|
|
||
| if ( | ||
| desc.internal !== false && | ||
| // TODO: Change 7.19.0 to the first version supporting internal plugins |
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 should be added to the make new-version-checklist.
| "@babel/helper-module-transforms": "workspace:^", | ||
| "@babel/helpers": "workspace:^", | ||
| "@babel/parser": "workspace:^", | ||
| "@babel/plugin-proposal-async-generator-functions": "workspace:^", |
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.
Q: Should we also internalize @babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression and @babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining?
Since we will defaults to bugfixes: true in Babel 8, I think they should be included in internal plugin set.
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.
Done 👍 I've left @babel/preset-modules out for now; we can decide what to do with it in the future :)
c19dc31 to
6c0d573
Compare
6c0d573 to
71b59ee
Compare
71b59ee to
f089bc8
Compare
bbf73ac to
9ce2fb7
Compare
9ce2fb7 to
ef7e6ed
Compare
ef7e6ed to
56346f2
Compare
|
I would love to receive some feedback on the plugin renaming suggested in the comment in While going through the list of all plugins, I noticed that some of them had very inconsistent naming. We have multiple options:
|
|
I'm a little concerned that this PR is blurring the distinction between At the same time, the advantages of purpose also have some limitations. The main way I understand in rfc to encourage users to upgrade is to deprecate the proposal that becomes the fourth phase, and use the package manager to remind users to upgrade But I don't block this PR, I just want to have more detailed discussions. 😃 |
|
|
||
| // ES2021 | ||
| "logical-assignment-operators": () => proposalLogicalAssignmentOperators, | ||
| "numeric-separator": () => proposalNumericSeparator, // RENAME: numeric-separators |
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.
For most plugins after ES2021, they are named from the corresponding proposal slug:
https://github.com/tc39/proposal-numeric-separator
https://github.com/tc39/proposal-class-static-block
I believe it is straightforward if you want to try out a plugin after you learn that proposal. If TC39 can somehow enforce consistent naming among proposals, that would be great. Otherwise I suggest we rename it but keep old name as an alias.
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 can discuss it with other TC39 delegates.
|
(I replied to @liuxingbaoyu in babel/rfcs#10) |
This is my first pass at implementing babel/rfcs#10. I didn't think about and responded to all the feedback yet.
So far this PR includes all the plugins in
@babel/core, and it's possible to do so already in v7 by just adding them as dependencies.@babel-core----(dependency)--->@babe/plugin-...---->(peerDependency)--->@babel/corecycles, but apparently we already had a@babel-core----(dependency)--->@babe/helper-compilation-targets---->(peerDependency)--->@babel/corecycle and no one complained, so it works in all the package managers.EDIT There is a big benefit I didn't think about: by simply updating
@babel/core, users can make sure that all their plugin for stable features are up to date.I still need to actually use the internal plugins in@babel/preset-env, to check that everything works.Additionally, while going through the list of all the stable plugins I noticed that some of them may benefit from a rename that either makes it more clear what they do, or makes their name consistent with the name of other plugins. You can read my proposals as comments in
packages/babel-core/src/transformation/internal-plugins.ts.