Skip to content

Conversation

@nicolo-ribaudo
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Sep 22, 2022

Q                       A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature? Yes
Tests Added + Pass? Yes
Documentation PR Link
Any Dependency Changes?
License MIT

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.

  • We now have a lot of @babel-core----(dependency)--->@babe/plugin-...---->(peerDependency)--->@babel/core cycles, but apparently we already had a @babel-core----(dependency)--->@babe/helper-compilation-targets---->(peerDependency)--->@babel/core cycle and no one complained, so it works in all the package managers.
  • Doing it this way doesn't give us any of the benefits of the RFC, except that we can start exposing in Babel 7 the same API that we will have in Babel 8.
    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.

@nicolo-ribaudo nicolo-ribaudo added PR: New Feature 🚀 A type of pull request used for our changelog categories pkg: core labels Sep 22, 2022
@babel-bot
Copy link
Collaborator

babel-bot commented Sep 22, 2022

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

@nicolo-ribaudo
Copy link
Member Author

nicolo-ribaudo commented Oct 6, 2022

This is ready for review. This change isn't much useful per se, because we cannot really move the plugins currently used by @babel/preset-env to @babel/core otherwise they would all be duplicated (once in @babel/preset-env's dependencies, and once inside @babel/core's source). However:

  • this PR prepares all the infrastructure, and as soon as we have to move a new plugin to @babel/preset-env we can do so by making it a "real" internal @babel/core plugin rather than a new dependency. I'm eagerly waiting for a proposal to get to Stage 4 :)
  • this PR doesn't change the size of the @babel/core & @babel/preset-env combo.
  • this PR doesn't move bugfix plugins yet into @babel/core, we can discuss if we should do it or not (probably yes?), but this PR is already quite big and we don't need to move them now.

While reviewing, please take a look at the comments in packages/babel-core/src/transformation/internal-plugins.ts because I would like to decide the naming before merging (otherwise we have to wait for Babel 8)

@nicolo-ribaudo nicolo-ribaudo marked this pull request as ready for review October 6, 2022 13:36

if (
desc.internal !== false &&
// TODO: Change 7.19.0 to the first version supporting internal plugins
Copy link
Contributor

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:^",
Copy link
Contributor

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.

Copy link
Member Author

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 :)

@nicolo-ribaudo nicolo-ribaudo added this to the v7.21.0 milestone Dec 6, 2022
@JLHwung JLHwung self-requested a review December 7, 2022 15:42
@nicolo-ribaudo nicolo-ribaudo added the PR: Needs Review A pull request awaiting more approvals label Feb 8, 2023
@nicolo-ribaudo
Copy link
Member Author

I would love to receive some feedback on the plugin renaming suggested in the comment in internal-plugins.ts, even from those that will not review this.

While going through the list of all plugins, I noticed that some of them had very inconsistent naming. We have multiple options:

  • don't rename them
  • rename them now for the internal plugins, and keep the old name for the plugin packages
  • don't rename them now, add aliases later for the internal plugins, and keep the old name for the plugin packages. Remove the old names in Babel 8.
  • don't rename them now, and do the rename in Babel 8.0.0.

@liuxingbaoyu
Copy link
Member

I'm a little concerned that this PR is blurring the distinction between @babel/core and @babel/preset-env.
Previously @babel/core was a framework, while @babel/preset-env resembled a convenient collection of plugins.
Now a large number of plugins are included in @babel/core, and only a few remain in @babel/preset-env, which is not very ideal.

At the same time, the advantages of purpose also have some limitations.
Mainly it is the proposals that reach the fourth stage to benefit, but they are rarely affected by @babel/core, @babel/traverse, because bug fixes and standard alignment also happen more in <=3 proposals and ts. (now the ts plugin is widely used, and ts fixes and feature support often want newer @babel/core)

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 @babel/core.
This appears to be a "soft limit" only, we still need compatibility for older versions of @babel/core. And once we implement "hard limits", the soft limits will no longer be necessary and we will be able to reap most of these benefits.

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
Copy link
Contributor

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.

Copy link
Member Author

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.

@nicolo-ribaudo
Copy link
Member Author

(I replied to @liuxingbaoyu in babel/rfcs#10)

@nicolo-ribaudo nicolo-ribaudo removed this from the v7.21.0 milestone Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pkg: core PR: Needs Docs PR: Needs Review A pull request awaiting more approvals PR: New Feature 🚀 A type of pull request used for our changelog categories

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants