Ensure class decorators can access decorated non-static members

[JLHwung]

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

• Introduce a new runtime helper applyDecs2203R based on applyDecs2203, which lazily apply class decorations so that the class decorate will have access to the decorated non-static class elements. Because the return type is changed, we have to create a new runtime. In Babel 8 we can remove deprecated helpers applyDecs2203 and applyDecs
• Optimize the output when only the class is decorated or elements are decorated

This PR slightly increases the output size:

// before
[_init_a, _initProto] = babelHelpers.applyDecs2203(Foo, [[dec, 1, "a"]], []);
// after
[_init_a, _initProto] = babelHelpers.applyDecs2203R(Foo, [[dec, 1, "a"]], []).e;

We could preserve the output size if applyDecs2203R can return a customized iterator, i.e.

yield* applyMemberDecs(targetClass, memberDecs);
yield* applyClassDecs(targetClass, classDecs);

but then our runtime helper will not be ES5-compliant. We can revisit this approach if we bump helper targets in the future.

[JLHwung]

The class decorators are applied after member decorators are applied and bound to the initializer locals, such as initA, initProto, etc.

[babel-bot]

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

[liuxingbaoyu]

The CI failure looks related.

[JLHwung]

Yes. CI is failing for the same reason of #14836 (comment). I will investigate how I can resolve it without renaming functions.

[nicolo-ribaudo]

Helper diff: https://www.diffchecker.com/wMz5rhsx/

[JLHwung]

The e2e build was failing because we simply concat all helper codes in build-external-helpers:

babel/packages/babel-core/src/tools/build-external-helpers.ts

Lines 172 to 181 in 6e03af1

	helpers.list.forEach(function (name) {
	if (allowlist && allowlist.indexOf(name) < 0) return;
	const ref = (refs[name] = getHelperReference(name));
	helpers.ensure(name, File);
	const { nodes } = helpers.get(name, getHelperReference, ref);
	body.push(...nodes);
	});

which forms the content of the virtual \u0000RollupPluginBabelHelpers module created by the rollup Babel plugin.

A proper fix would be to handle function name collisions in build-external-helpers, but given that in most cases, the function names collide because we intend to replace the runtime with a new version. With the old runtime deprecated and hopefully removed in the next major, I think wrapping it into a factory is sufficient.

[nicolo-ribaudo]

@JLHwung The Attempted to decorate a public method/accessor that has the same name as a previously decorated public method/accessor. This is not currently supported by the decorators plugin. Property name was: error has been removed from the new helper: is it now supported, or was that error just unreachable?

This PR slightly increases the output size:

It's fine, decorators are already considered heavy and this is just a few more bytes.

[JLHwung]

The Attempted to decorate a public method/accessor that has the same name as a previously decorated public method/accessor. This is not currently supported by the decorators plugin. Property name was: error has been removed from the new helper

That part is not changed:

5dbfd3d#diff-1055897236adecf62778dc76b5b6168bc5c14344106b32a8a14c78479f601cb2R397

The only revisions are that applyMemberDecs and applyClassDecs now return the ret array, and the applyDecs returns an object served as a 2-item iterator. I can rewrite the commit history so we can easily review the difference.