fix: wrap anonymous class expression within statement

[JLHwung]

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

Babel currently throws at decorated anonymous class expression, e.g. @dec class { static {} } because we invoked t.toStatement. Here we wrap the class expression within an expression statement so that it can be fit in the static block that we used for class decorators.

Before develop this issue I realize that Babel doesn't support the named evaluation for decorated class expression, for example

const dec = (value, context) => {
  context.name; // <-- should be "A", currently "_class"
  return value;
};

let A;
A = @dec class {}

TypeScript injects __setFunctionName helper call before applying the decorator transform to ensure that context.name is always correct (microsoft/TypeScript#50820 (comment)). I will address this issue in a separate PR.

[babel-bot]

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

[liuxingbaoyu]

Would it be better to fix in t.toStatement?

Also unrelated to this PR, the type definition and implementation of t.toStatement seem inconsistent.

[JLHwung]

Would it be better to fix in t.toStatement?

I don't know much context here but it seems that we intentionally fail toStatement for anonymous class expression

babel/packages/babel-types/test/converters.js

Lines 131 to 138 in 53185ea

	it("fail if class expression has no id", function () {
	const node = t.classExpression(null, null, t.classBody([]), []);
	expect(function () {
	t.toStatement(node);
	}).toThrow(Error);
	expect(t.toStatement(node, /* ignore = */ true)).toBe(false);
	t.assertClassExpression(node);
	});

/cc @nicolo-ribaudo if you can shred some light here.

If we decided to overturn this behaviour, we still need the patch here until Babel 8 because the plugin does not depend on @babel/types.

[liuxingbaoyu]

liuxingbaoyu@98ca541

Good find, now I think it's fine.

[nicolo-ribaudo]

I believe the reason is that t.toStatement of a ClassExpression should return a ClassDeclaration, but converting a class expression without an ID is generally not safe.

[JLHwung]

toStatement wraps assignment expression within expression statement.