TypeScript enum transform does not treat const string variables as compile-time constants

[kdy1]

Describe the bug

SWC does not treat a local const string variable used in a TypeScript enum initializer as a compile-time constant.

For the input below, TypeScript 5.9 emits a string enum shape (E["A"] = "aThisIs"), but SWC emits reverse-mapping style output (E[E["A"] = foo] = "A"), which changes runtime behavior and enum shape.

Input code

const foo = 'aThisIs'

enum E {
  A = foo,
  B = 'bThisIs'
}

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript"
    }
  }
}

Link to the code that reproduces this issue

nodejs/amaro#394

SWC Info output

$ npx -y -p @swc/cli@latest -p @swc/core@latest swc -V
@swc/cli: 0.8.0
@swc/core: 1.15.18

Expected behavior

SWC should match TypeScript enum lowering semantics for this case (string enum, no reverse mapping for A), e.g.:

"use strict";
const foo = 'aThisIs';
var E;
(function (E) {
    E["A"] = "aThisIs";
    E["B"] = "bThisIs";
})(E || (E = {}));

Actual behavior

SWC currently emits:

var foo = 'aThisIs';
var E = function(E) {
    E[E["A"] = foo] = "A";
    E["B"] = "bThisIs";
    return E;
}(E || {});

Version

@swc/core 1.15.18 (@swc/cli 0.8.0)

Additional context

• Original downstream report: The generation of enum did not consider compile-time constant variables nodejs/amaro#394
• Related esbuild issue: Incorrect code for enums generated evanw/esbuild#4387

[kdy1]

@claude Please fix

[claude]

Claude finished @kdy1's task in 8m 49s —— View job • claude/issue-11715-20260320-0910 • Create PR ➔

---

Fixing const string variable handling in TypeScript enum transform

• Locate the enum transform code and understand how enum values are evaluated
• Implement const string variable resolution in enum initializer evaluation
• Add fixture test for the reported case
• Run full tests and verification (cargo test, cargo fmt, cargo clippy)
• Commit and push changes

Changes made:

1. ts_enum.rs — Added ConstVarRecord type alias and a const_vars field to EnumValueComputer. In compute_rec, when an identifier isn't found in the enum record, it now checks the const_vars map for const variable bindings with string/number values.

2. semantic.rs — Added const_vars field to SemanticInfo and a visit_var_decl method in the semantic analyzer that collects const variable declarations with string/number literal initializers. The const vars map is passed to EnumValueComputer.

3. Fixture test — Added tests/fixture/issue-11715/ with the exact reproduction case from the issue.

Output now matches TypeScript:

const foo = 'aThisIs';
var E = /*#__PURE__*/ function(E) {
    E["A"] = "aThisIs";
    E["B"] = "bThisIs";
    return E;
}(E || {});

|

[magic-akari]

As noted in the esbuild issue, providing an explicit type for foo triggers a regression to TypeScript 4.9 behavior.

const foo = "aThisIs"; // Original issue, TS 5.0 behavior

const foo: string = "aThisIs"; // Explicit type annotation, reverts to TS 4.9 behavior
const foo: "aThisIs" = "aThisIs"; // Explicit type annotation, reverts to TS 4.9 behavior
const foo = "aThisIs" as string; // Type assertion, reverts to TS 4.9 behavior
const foo = "aThisIs" as const; // Const assertion, reverts to TS 4.9 behavior
const foo = "aThisIs" as "aThisIs"; // Type assertion, reverts to TS 4.9 behavior

Given the potential implications regarding TypeScript Design Non-goal#5 , this case should be reported to the TypeScript team for validation before any local fixes are merged.

[magic-akari]

TS team confirmed in microsoft/TypeScript#63275 that this behavior is intentional and stable.
We should align with it as described in evanw/esbuild#4387.
Some cases are non-trivial.