Replace `computed` field on `TSEnumMember` with more enum variants on `TSEnumMemberName`

[overlookmotel]

#10092 introduced a computed field on TSEnumMember, in order to align with TS-ESLint.

oxc/crates/oxc_ast/src/ast/ts.rs

Lines 122 to 127 in fa97b6c

	pub struct TSEnumMember<'a> {
	pub span: Span,
	pub id: TSEnumMemberName<'a>,
	pub computed: bool,
	pub initializer: Option<Expression<'a>>,
	}

I suggest that we remove this field and instead have more variants on TSEnumMemberName:

pub enum TSEnumMemberName<'a> {
    Identifier(Box<'a, IdentifierName<'a>>),
+   ComputedIdentifier(Box<'a, IdentifierName<'a>>),
    String(Box<'a, StringLiteral<'a>>),
+   ComputedString(Box<'a, StringLiteral<'a>>),
-   TemplateString(Box<'a, TemplateLiteral<'a>>),
+   ComputedTemplateString(Box<'a, TemplateLiteral<'a>>),
}

There are 2 reasons I feel this is preferable:

1. Shrink TSEnumMember by 8 bytes.
2. Make it impossible to represent an illegal syntax in AST:

enum Foo {
    // Illegal syntax - template strings must be computed
    `X` = 1,
}

computed: false is not valid when member name is a TemplateLiteral.

---

Note: I had thought that computed Identifiers are also illegal ([A] = 1), but it appears that's a typechecking error, not a parse error.

Both TS and @typescript-eslint/parser accept this syntax when parsing only (type-checking disabled):

TS Playground
TS-ESLint AST explorer

[overlookmotel]

cc @leaysgur

[Boshen]

I don't have a preference, either choice has some pros and cons :-/

[overlookmotel]

Concerning whether ComputedIdentifier variant is required or not:

@leaysgur Pointed out in #10346 (comment) that TypeScript parser and TS-ESLint parser accept any expression in a computed member key. e.g.:

enum Foo {
    ['a' + 'b'] = 1,
    [bar] = 2,
    [qux()] = 3,
    [await foo.bar.qux()] = 4,
}

They also support NumericLiteral as a non-computed key:

enum Foo {
    1 = 2,
    3 = 4,
}

I notice that TS-ESLint also parses BigIntLiteral as non-computed key! (although the type defs exclude that)

enum Foo {
    123n = 2,
}

TS-ESLint AST explorer

Type defs:

• TSEnumMember.id: PropertyNameComputed | PropertyNameNonComputed
  • https://github.com/typescript-eslint/typescript-eslint/blob/7f23300d0d23e5abbb7b86f8c40bafd7730901e1/packages/ast-spec/src/element/TSEnumMember/spec.ts#L12-L14
• Computed = Expression, NonComputed = Identifier + StringLiteral + NumberLiteral
  • https://github.com/typescript-eslint/typescript-eslint/blob/7f23300d0d23e5abbb7b86f8c40bafd7730901e1/packages/ast-spec/src/unions/PropertyName.ts#L11-L15

The only patterns which are legal as far as TS type checker is concerned are:

enum Foo {
    A,
    "B",
    ["C"],
    [`D`],
}

Anything else is a type check error, and therefore can't be transformed to JS.

We have decided to keep it as it is for now and continue to treat the typecheck errors as parser errors, therefore these patterns don't need to be represented in AST. We can revisit this decision if we find later on that supporting other options is required to pass TS-ESLint conformance tests.