Skip public class property transform when possible

[JLHwung]

Q	A
Fixed Issues?	Skip properties transform under certain circumstances (see below)
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

In this PR we skip proposal-class-properties transform when all of the following conditions are satisfied

• The targets has native support of class properties
• There is no private element or static block inside class body
• The class and its elements are not decorated

I think we should discuss about where we should put the granular compat data. In this case it is the public_class_fields used only in proposal-class-properties transform. I put this table in helper-create-features-plugin, which is how a third-party plugin author would have done if he/she wants to implement granular control on the plugin output given different api.targets().

[babel-bot]

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

[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 e912525:

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

[nicolo-ribaudo]

I think it's easier for us to keep all our own data in @babel/compat-data, but we can still keep the "granular data" in a different file from the main plugins data (similarly to what we do for bugfixes).

Fyi, I did something like this in #12899 where I re-used existing @babel/compat-data data.

[nicolo-ribaudo]

Please don't directly import .json files, since it won't work when moving to native ESM 🙏

Ref #12759

[JLHwung]

💔 https://nodejs.org/api/esm.html#esm_json_modules is still experimental.

[nicolo-ribaudo]

What do you think about splitting the private and public transforms instead? If a class contains both private and public fields, we could still leave public fields intact.

[JLHwung]

If a class contains both private and public fields, we could still leave public fields intact.

I don't think we can leave public fields intact, for example when private elements are referenced in the initializer.

class C {
  #a = 1;
  b = this.#a;
}

[nicolo-ribaudo]

Well that can be compiled to

class C {
  b = (INITIALIZE(this, #a, 1), this.#a);
}

which means

class C {
  b = (_a.set(this, { writable: true, value: 1 }), _classPrivateFieldGet(this, _a))
}

anyway, this PR is already a good step in the correct direction.