Support computed property names in enums

[dsherret]

Describe the bug

The following code works in TypeScript, but not in swc.

Input code

enum CHAR {
    ["\t"] = 0x09,
    ["\n"] = 0x0A,
    ["\v"] = 0x0B,
    ["\f"] = 0x0C,
    ["\r"] = 0x0D,
    [" "]  = 0x20,

    ["-"] = 0x2D,
    ["["] = 0x5B
}

const c = "\n"

console.log(c.charCodeAt(0) === CHAR["\n"]);

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false
    },
    "target": "es5",
    "loose": false,
    "minify": {
      "compress": false,
      "mangle": false
    }
  },
  "module": {
    "type": "es6"
  },
  "minify": false,
  "isModule": true
}

Link to the code that reproduces this issue

https://play.swc.rs/?version=1.13.20&code=H4sIAAAAAAAAA0vNK81VcPZwDFKo5uVSAIJopZgSpVgFWwWDCgNLHbhYHkzMESFWBhNzQoilwcScEWJFMDEXuJgCUAgsZmQAFIOJ6kIVGiEURkOFTJ14uWpBKpPz84pLFJKBgiBHwUTyc1L1cvLTNZL1kjMSi5zzU1IdSzQMNBVsbW3BvoP4QNMaABH2NC7vAAAA&config=H4sIAAAAAAAAA1WPSw7DIAwF9zkF8rrbdtE79BCIOhERP9mOVBTl7oUE0maH3xszsA5KwcwGnmotxzIkTYx0ziXhHER%2FSgKSE7IhmwRuvRWu1agd4x5tRwOiaUKpW8j3hoOLkbHjLfM22DH%2FC030iZD5ClZUh8nhVTc0Jfj4XvayfaQ%2B9tA%2F4Ad12XkxWH71TaEFh%2B0LYuVI0xQBAAA%3D

SWC Info output

No response

Expected behavior

Should not error.

Actual behavior

x Computed property names are not allowed in enums
,-[input.ts:2:1]
1 | enum CHAR {
2 | ["\t"] = 0x09,
: ^^^^^
3 | ["\n"] = 0x0A,
4 | ["\v"] = 0x0B,
4 | ["\f"] = 0x0C,
`----

Version

1.13.20

Additional context

No response

[dsherret]

Additionally, as a const enum this should probably work:

const enum CHAR {
    ["\n"] = 0x0A,
}

const c = "\n"

console.log(c.charCodeAt(0) === CHAR["\n"]);

[magic-akari]

Thank you for reporting this issue. I've investigated TypeScript's official implementation to understand how computed property names in enums should be handled.

Current Findings

TypeScript's compiler does support computed property names in enums, but only with string or template string literal expressions. Non-literal expressions will produce an error.

Allowed:

enum CHAR {
    foo = 1,        // ✅ Regular enum member

    '\t' = 0x09,    // ✅ String literal
    "\n" = 0x0A,    // ✅ String literal

    ['\v'] = 0x0B,  // ✅ String literal within brackets
    ["\f"] = 0x0C,  // ✅ String literal within brackets
    [`\r`] = 0x0D,  // ✅ Template literal (no substitution) within brackets
}

Not allowed:

enum TEST {
    `-` = 0,                  // ❌ Template literal outside brackets - Error TS2364
    ["a" + "b"] = 1,          // ❌ Binary expression - Error TS1164
    [`hello ${"world"}`] = 2, // ❌ Template literal with substitution - Error TS1164
}

You can verify this behavior in the TypeScript Playground.

TypeScript's Implementation

AST Definition

types.ts:3601-3608:

export interface EnumMember extends NamedDeclaration, JSDocContainer {
    readonly kind: SyntaxKind.EnumMember;
    readonly parent: EnumDeclaration;
    // This does include ComputedPropertyName, but the parser will give an error
    // if it parses a ComputedPropertyName in an EnumMember
    readonly name: PropertyName;  // PropertyName includes ComputedPropertyName
    readonly initializer?: Expression;
}

Warning

The comment states that "the parser will give an error if it parses a ComputedPropertyName in an EnumMember", but the actual implementation behaves differently. As shown in the Playground above, the parser does not emit errors for computed property names like ["\t"] or [`hello`] in enums. The actual validation occurs in the type checker (see checker.ts:47808), which only rejects non-literal computed expressions like ["a" + "b"].

types.ts:1736-1743

export type PropertyName =
    | Identifier
    | StringLiteral
    | NoSubstitutionTemplateLiteral
    | NumericLiteral
    | ComputedPropertyName  // ← Includes this
    | PrivateIdentifier
    | BigIntLiteral;

Parser Implementation

parser.ts:8262-8268:

function parseEnumMember(): EnumMember {
    const pos = getNodePos();
    const hasJSDoc = hasPrecedingJSDocComment();
    const name = parsePropertyName();  // ← Accepts any PropertyName, including ComputedPropertyName
    const initializer = allowInAnd(parseInitializer);
    return withJSDoc(finishNode(factory.createEnumMember(name, initializer), pos), hasJSDoc);
}

parser.ts:2733-2745

function parseComputedPropertyName(): ComputedPropertyName {
    const pos = getNodePos();
    parseExpected(SyntaxKind.OpenBracketToken);
    // We parse any expression (including a comma expression). But the grammar
    // says that only an assignment expression is allowed, so the grammar checker
    // will error if it sees a comma expression.
    const expression = allowInAnd(parseExpression);  // ← Parses any expression
    parseExpected(SyntaxKind.CloseBracketToken);
    return finishNode(factory.createComputedPropertyName(expression), pos);
}

Type Checker Validation

checker.ts:47807-47810:

function computeEnumMemberValue(member: EnumMember, autoValue: number | undefined, previous: EnumMember | undefined): EvaluatorResult {
    if (isComputedNonLiteralName(member.name)) {
        error(member.name, Diagnostics.Computed_property_names_are_not_allowed_in_enums);
    }
    // ...
}

utilities.ts:2318-2320:

export function isComputedNonLiteralName(name: PropertyName): boolean {
    return name.kind === SyntaxKind.ComputedPropertyName &&
           !isStringOrNumericLiteralLike(name.expression);
}

Key insight: The parser accepts any expression in computed property names, but the type checker validates that only literal expressions are used.

TypeScript (Go version)

The Go port follows the exact same architecture as the TypeScript version.

AST Definition (ast.go:2075):

// PropertyName is a type alias for Node that can be one of:
// Identifier | StringLiteral | NoSubstitutionTemplateLiteral |
// NumericLiteral | ComputedPropertyName | PrivateIdentifier | BigIntLiteral
PropertyName = Node

EnumMember Definition (ast.go:4422-4429):

type EnumMember struct {
    NodeBase
    NamedMemberBase        // Contains: name *PropertyName
    compositeNodeBase
    Initializer *Expression // Optional
}

func (f *NodeFactory) NewEnumMember(name *PropertyName, initializer *Expression) *Node {
    data := &EnumMember{}
    data.name = name       // ← PropertyName, includes ComputedPropertyName
    data.Initializer = initializer
    return f.newNode(KindEnumMember, data)
}

ComputedPropertyName Definition (ast.go:2774-2778):

type ComputedPropertyName struct {
    NodeBase
    compositeNodeBase
    Expression *Expression // Any expression
}

Parser Implementation (parser.go:1986-1994):

func (p *Parser) parseEnumMember() *ast.Node {
    pos := p.nodePos()
    hasJSDoc := p.hasPrecedingJSDocComment()
    name := p.parsePropertyName()  // ← Accepts any PropertyName, including ComputedPropertyName
    initializer := doInContext(p, ast.NodeFlagsDisallowInContext, false, (*Parser).parseInitializer)
    result := p.finishNode(p.factory.NewEnumMember(name, initializer), pos)
    p.withJSDoc(result, hasJSDoc)
    return result
}

parsePropertyName calls parsePropertyNameWorker (parser.go:3302-3321):

func (p *Parser) parsePropertyName() *ast.Node {
    saveHasAwaitIdentifier := p.statementHasAwaitIdentifier
    prop := p.parsePropertyNameWorker(true /*allowComputedPropertyNames*/)
    p.statementHasAwaitIdentifier = saveHasAwaitIdentifier
    return prop
}

func (p *Parser) parsePropertyNameWorker(allowComputedPropertyNames bool) *ast.Node {
    if p.token == ast.KindStringLiteral || p.token == ast.KindNumericLiteral || p.token == ast.KindBigIntLiteral {
        literal := p.parseLiteralExpression(true /*intern*/)
        return literal
    }
    if allowComputedPropertyNames && p.token == ast.KindOpenBracketToken {
        return p.parseComputedPropertyName()  // ← Allows computed names
    }
    if p.token == ast.KindPrivateIdentifier {
        return p.parsePrivateIdentifier()
    }
    return p.parseIdentifierName()
}

parseComputedPropertyName (parser.go:3323-3335):

func (p *Parser) parseComputedPropertyName() *ast.Node {
    // PropertyName [Yield]:
    //      LiteralPropertyName
    //      ComputedPropertyName[?Yield]
    pos := p.nodePos()
    p.parseExpected(ast.KindOpenBracketToken)
    // We parse any expression (including a comma expression). But the grammar
    // says that only an assignment expression is allowed, so the grammar checker
    // will error if it sees a comma expression.
    expression := p.parseExpressionAllowIn()  // ← Parses ANY expression
    p.parseExpected(ast.KindCloseBracketToken)
    return p.finishNode(p.factory.NewComputedPropertyName(expression), pos)
}

Type Checker Validation (checker.go:23183-23192):

func (c *Checker) computeEnumMemberValue(member *ast.Node, autoValue jsnum.Number, previous *ast.Node) evaluator.Result {
    if ast.IsComputedNonLiteralName(member.Name()) {
        c.error(member.Name(), diagnostics.Computed_property_names_are_not_allowed_in_enums)
    } else if ast.IsBigIntLiteral(member.Name()) {
        c.error(member.Name(), diagnostics.An_enum_member_cannot_have_a_numeric_name)
    } else {
        text := ast.GetTextOfPropertyName(member.Name())
        if isNumericLiteralName(text) && !isInfinityOrNaNString(text) {
            c.error(member.Name(), diagnostics.An_enum_member_cannot_have_a_numeric_name)
        }
    }
    // ...
}

IsComputedNonLiteralName (utilities.go:2089):

func IsComputedNonLiteralName(name *Node) bool {
    return IsComputedPropertyName(name) && !IsStringOrNumericLiteralLike(name.Expression())
}

Key insight: The Go implementation has the identical architecture to the TypeScript version:

1. Parser accepts any expression in [...]
2. Checker validates that only string/numeric literals are allowed
3. Error is reported in the checker, not the parser

typescript-eslint's Implementation

SWC is planning to align its AST structure with typescript-eslint's AST specification, making their implementation particularly relevant for our design decisions.

AST Definition (spec.ts):

export interface TSEnumMember extends BaseNode {
  type: AST_NODE_TYPES.TSEnumMember;
  id: Identifier | StringLiteral;  // ← Only Identifier or StringLiteral
  initializer: Expression | undefined;
  /**
   * @deprecated the enum member is always non-computed.
   */
  computed: boolean;  // ← Deprecated property
}

Warning

typescript-eslint does NOT support computed property names in its AST definition, which differs from TypeScript's current compiler implementation. The computed property is marked as deprecated with a note saying "the enum member is always non-computed".

You can verify typescript-eslint's behavior in the typescript-eslint playground.

---

Next Steps

While investigating the implementations above, two inconsistencies were discovered (see WARNING sections). Before implementing a fix in SWC, we need to clarify these with the TypeScript team and the typescript-eslint team to understand the intended behavior and future direction of this feature.

---

[magic-akari]

Hi @bradzacher! 👋

Quick question about typescript-eslint's AST design for enum members:

I noticed that TSEnumMember.computed is deprecated with "the enum member is always non-computed", and the id field only accepts Identifier | StringLiteral. However, TypeScript's compiler does accept literal computed property names like ['\t'] in enums.

Since we're planning to align SWC's AST with typescript-eslint, I'm wondering if this was a deliberate design decision—perhaps TypeScript plans to deprecate this feature and typescript-eslint is ahead of the curve?

Would love to hear your thoughts when you have a chance!

[bradzacher]

Hmm. I think there was a miscommunication and some crossed wires during the PR.

Computed members are allowed if and only if the expression is a string literal or a template literal with no expressions.

Essentially there were two things banned in the implementing PR (typescript-eslint/typescript-eslint#11232) - bigint literals and computed keys.

The author listed two issues in the TS repo microsoft/TypeScript#61772 and microsoft/TypeScript#61834 for the two features, respectively.

The first issue (banning bigint literals) was accepted and merged into TS.

The second issue (banning computed properties altogether) was closed as a duplicate of microsoft/TypeScript#42468.
I must not have looked closely enough or followed-up properly with respect to the issue and somehow missed that it wasn't closed as fixed.

So technically it's erroneous that we disallow computed properties with literals.

That being said - nobody sane writes such code - as evidenced by the fact that we are yet to get a bug report about it. Also Ryan from the TS team even said in the issue, quote "I don't know why we added that logic 😕". Additionally babel also never implemented support for the syntax.

So yeah - part of me says "oops this is a bug we should revert"... But also I don't think we should bother because whilst it is technically incorrect - it's the state the world should be in AND nobody will notice or care either.

[bradzacher]

I'm on mobile and I don't have access to a computer for a while - but would be worth checking if tsgo supports the syntax.

If it does we should consider pushing on the TS team to kill it, given nobody wants the syntax lol. Add it to the list of breaking changes that tsgo will ship with!

[magic-akari]

Thanks so much for the detailed explanation and honesty, Brad! Really appreciate you taking the time to dig into the history behind this. 🙏

To answer your question: yes, typescript-go does support the syntax. The Go implementation follows the same architecture as TypeScript (parser accepts, type checker validates literals only).

---

Our plan for SWC

Our approach is to keep our AST aligned with typescript-eslint (no computed property support in the AST)

For the parser layer, we're considering two options:

• Option A: Don't implement parser support at all
• Option B: Accept the syntax in parser and normalize to non-computed form (e.g., ['\t'] → '\t')

Rationale for Option A:

• Both typescript-eslint and Babel don't support this syntax
• Aligns with the most widely-used implementations

If we go with Option B:

• Would improve compatibility with TypeScript/typescript-go
• Parser accepts, but AST stays simple (normalized to StringLiteral)

@kdy1 what do you think? I'm still waiting for feedback from the TypeScript team but wanted to get your thoughts on the two options.

---

We'll also keep an eye on the typescript-go discussions. If there's official movement towards deprecating this, we'll be well-positioned either way.

Thanks again for the insights, Brad!

[kdy1]

In the case we need to support it, I prefer option B, mainly because it’s an AST and we can avoid a breaking Wasm plugins. AST does not have to hold every information from the source code, and normalization makes handling AST simpler