Compile static blocks without the intermediate priv field step

[nicolo-ribaudo]

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

Consider this config:

{
  "presets": [
     {
       "plugins": ["proposal-class-static-block", "proposal-private-methods", "proposal-class-properties"]
     },
     "@babel/preset-env"
  ]
}

Until Babel 7.14.0, this was fine: the proposal-class-static-block was enabled before the other class features plugins, so that it could compile static blocks to private fields.

However, starting from Babel 7.14.0 @babel/preset-env automatically enabled the class fields and private methods plugins: the new effective order is

- proposal-private-methods
- proposal-class-properties
- proposal-class-static-block
- proposal-private-methods
- proposal-class-properties

This breaks, because the proposal-class-properties plugin runs before proposal-class-static-block (and the only way to workaround it is to change the presets order in the user config).

We can avoid this problem by transforming static blocks in Program:enter: it's safe, because the transform is quite self-contained so it doesn't cause problem if there are some proposals between the program node and the class node.

Regardless of the behavior change introduced in 7.14.0, this is something that makes it easier to configure Babel since it's one less thing our users have to worry about.

I hope to properly solve this problem with something like #13260.

[nicolo-ribaudo]

This is just indented

[babel-bot]

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

[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 6a7ab1b:

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

[JLHwung]

Traversing the whole program to transform static block can be slow. And what if in the future we decide to compile some feature to Static Block? Can we apply the class transform on Class:exit? If so we can listen to StaticBlock:exit and their order constraints can be resolved, too.

Another thought may be introducing visitor.order: number, which can be considered as a generalization of start (Infinity) and exit (-Infinity), we can then allocate different orders to plugins so when they combine together, they work as we expected.

[nicolo-ribaudo]

@JLHwung That would cause problems, because the private-in transform relies on the fact that private fields are transformed before visiting the class body to automatically disable itself. Another possibility is to just handle static blocks in the helper-class-features plugin.

[nicolo-ribaudo]

I solved this in another way, that also makes the generated code smaller when compiling both static blocks and class fields.

Technically it's a new feature for the internal @babel/helper-create-class-features-plugin, but I think that it can go in a patch because from a user perspective it's just:

• a relaxed plugin ordering constraint
• a more optimized output

[nicolo-ribaudo]

I think this is a bug (the super class is evaluated twice), but the bug was present also before this PR.