Typescript namespaces lead to `ReferenceError`

[mischnic]

Describe the bug

Coming from vercel/next.js#89136

Input code

export namespace Test {
    export const a = 1;
}

export namespace Test {
    export const b = a + 1;
}

Config

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false
    },
    "minify": {
      "compress": false,
      "mangle": false
    }
  },
  "module": {
    "type": "es6"
  },
  "minify": false,
  "isModule": true,
  "env": {
    "targets": "Safari 10"
  }
}

Link to the code that reproduces this issue

https://play.swc.rs/?version=1.15.11&code=H4sIAAAAAAAAA0utKMgvKlHIS8xNLS5ITE5VCEktLlGo5lIAglSIXHJ%2BHlAoUcFWwdCaq5aLK5VYLUlALYkK2mBtAOYCn9toAAAA&config=H4sIAAAAAAAAA1WOMQ7CMAxF95wi8swACwN3YOIEVnCroCaN7BQRVb07SduEsvn%2Fbz%2F%2FWWkNLzFw03MeswjIQtx0diT5iJ%2FsQEyBxLANEU41jVKiDgeh1Vq2BJz1tktHjhldYBKp6w3h0PcD%2FVPUTgI3Pqc13PuVDqULyRV%2BS%2FVZA4OVe72MPG0e%2BfcBhNxTLG3ggR2y1ZfzSlTLF2pa2cwWAQAA

SWC Info output

No response

Expected behavior

compare with
Babel: https://babeljs.io/repl#?config_lz=N4IgZglgNgpgdgQwLYxALhAJxgBygOgBcBnEAGhB22JhPQG16RCBPHGYgY0wh0PNAIoUAPYB3ACIxOUBNgBiEGFAAmpNIUwBXGBSGixAOWQccCTh3SadAXwC6disRFbMFgCptUGJCJVbYEBsgA&code_lz=KYDwDg9gTgLgBAOwIYFtgGcxIMbDgFQ3gG8AoOCuUSWObCBdeJOAXjgEYBuUgX1NLVo8ZGkw48hJnDKUq4YXQbSARmzgsA1Jx68gA&version=7.28.6

and tsc: https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBAOwIYFtgGcxIMbDgFQ3gG8AoOCuUSWObCBdeJOAXjgEYBuUgX1NLVo8ZGkw48hJnDKUq4YXQbSARmzgsA1Jx68gA

Actual behavior

(function(Test) {
    Test.a = 1;
})(Test || (Test = {}));
(function(Test) {
    Test.b = a + 1; // undeclared variable
})(Test || (Test = {}));
export var Test;

Version

1.15.11

Additional context

No response

[kdy1]

Claude (@claude) fix it

[claude]

Claude finished Donny/강동윤 (@kdy1)'s task in 13m 19s —— View job • claude/issue-11514-20260129-0956 • Create PR ➔

---

Fixing TypeScript Namespace ReferenceError

• Understand the bug and locate relevant code
• Write a test case for the issue
• Implement the fix
• Run tests and verify the fix
• Commit and push changes

Summary: Fixed the issue where references to exports from merged namespace declarations were not being qualified with the namespace name, leading to ReferenceError at runtime.

Root Cause: The ExportQuery::query_ref method used exact Id matching (symbol + syntax context), but references to exports from merged namespace declarations have a different syntax context (unresolved) than the original export declaration.

Solution: Added a fallback lookup mechanism that matches by symbol name alone when the identifier has unresolved context. This handles the case where the resolver cannot resolve cross-namespace-declaration references.

Test Results: 193 tests passed (1 unrelated failure due to missing mocha in CI environment).

---

|

[magic-akari]

FYI: This isn't supported in TypeScript 7 either.

• tsgo fails to resolve namespace symbols in non-extends contexts across files microsoft/typescript-go#961
• 6.0 Deprecation List microsoft/TypeScript#54500

[rubenferreira97]

magic-akari I think there might be a misunderstanding regarding that deprecation. I’m currently using TypeScript 7 and this pattern is still supported. The change specifically targets cross-namespace value qualification where an unqualified name resolves to a sibling namespace member instead of an outer-scope variable.

As per the docs:

In TypeScript 6.0, this behavior will be removed, and bar will refer to the outer const...

We can still merge namespaces. We just can't rely on that specific unqualified name resolution behavior.

[magic-akari]

I’m currently using TypeScript 7 and this pattern is still supported.

Fair point, but rather than taking my word for it, I’d love for you to see it in action. I’ve put together a minimal reproduction that demonstrates this exact behavior.

You can clone it and run it locally to see how the compiler handles the resolution:

https://gist.github.com/magic-akari/c0ef945da74fc414ab04bb1342bf082c

git clone https://gist.github.com/c0ef945da74fc414ab04bb1342bf082c.git tsgo-reproduce-issue
cd tsgo-reproduce-issue
npm i
npm run build
# check the output

For reference, here is the output I’m seeing on my machine:

index.mjs

export { Test };
var Test;
(function (Test) {
    Test.a = 1;
})(Test || (Test = {}));
(function (Test) {
    Test.b = a + 1;
})(Test || (Test = {}));
//# sourceMappingURL=index.mjs.map

Please note that a is not being resolved here, which matches the current behavior of SWC.

Let me know if you see the same results on your end!

[rubenferreira97]

magic-akari You are right regarding the current behavior, but there does seem to be a mismatch when testing against the TypeScript 6.0 development branch. I will open an issue on typescript-go so we can investigate what the correct behavior should be and ensure parity with the official compiler.

I tested this using the following configuration:

package.json

{
  "name": "bun",
  "module": "index.ts",
  "type": "module",
  "private": true,
  "devDependencies": {
    "@types/bun": "latest",
    "@typescript/native-preview": "latest",
    "typescript": "^6.0.0-dev.20260129"
  }
}

When running bunx tsc --outDir out/tsc6, the output correctly qualifies the member:

export var Test;
(function (Test) {
    Test.a = 1;
})(Test || (Test = {}));
(function (Test) {
    // Correctly qualified as Test.a
    Test.b = Test.a + 1;
})(Test || (Test = {}));
console.log(Test.b);

However, bunx tsgo --outDir out/tsgo produces an unqualified reference that leads to a ReferenceError:

export { Test };
var Test;
(function (Test) {
    Test.a = 1;
})(Test || (Test = {}));
(function (Test) {
    // Unqualified 'a' will fail to resolve
    Test.b = a + 1;
})(Test || (Test = {}));
console.log(Test.b);

[jakebailey]

We talked about this, and we're just not going to change this behavior, so do need a PR to correct tsgo. We want 6.0 to be soon, and now that the checker is already being used in emit anyway, this doesn't seem worth changing. There are other people out there that are broken for this too, and same for enums potentially.

(EDIT: sorry, I meant to reply to the TS issue not here, but, I guess the above is okay knowledge)

[kdy1]

Claude (@claude) Read all the comments and investigate the cause. Also, propose a solution.

[claude]

Claude finished Donny/강동윤 (@kdy1)'s task in 3m 41s —— View job

---

Investigation: TypeScript Namespace ReferenceError

• Read and analyze all comments in the issue
• Investigate the root cause in the codebase
• Review the previous fix attempt
• Propose a solution based on findings

---

Summary of Discussion

The issue involves TypeScript namespaces where merged namespace declarations produce incorrect code:

export namespace Test {
    export const a = 1;
}

export namespace Test {
    export const b = a + 1;  // References 'a' from first declaration
}

Current SWC output (broken):

(function(Test) { Test.a = 1; })(Test || (Test = {}));
(function(Test) { Test.b = a + 1; })(Test || (Test = {}));  // ReferenceError: 'a' is not defined

Expected output (correct):

(function(Test) { Test.a = 1; })(Test || (Test = {}));
(function(Test) { Test.b = Test.a + 1; })(Test || (Test = {}));  // Correct!

Key Points from Comments

1. magic-akari pointed out that TypeScript Go (tsgo) produces the same broken output as SWC
2. Rúben Ferreira (@rubenferreira97) clarified that the deprecation notice (TypeScript 6.0) only targets a specific case where an unqualified name resolves to a sibling namespace member instead of an outer-scope variable. The pattern itself is still supported.
3. Testing showed:
   • TypeScript 6.0 dev branch (tsc): Produces correct output with Test.a
   • TypeScript Go (tsgo): Produces broken output with bare a
4. Jake Bailey (@jakebailey) (TypeScript team): They decided NOT to change tsgo's behavior for this release. However, this is acknowledged as a deviation from tsc behavior.

Root Cause Analysis

The issue is in crates/swc_ecma_transforms_typescript/src/transform.rs. The transformation process:

1. Visit phase (lines 106-219): Collects exported_binding which maps Id → Option<Id> (export identifier to namespace identifier)
2. VisitMut phase: Uses RefRewriter with ExportQuery to replace bare identifier references with qualified namespace members

The problem: When processing the second namespace declaration, references to a have an unresolved syntax context (because the resolver can't resolve cross-namespace-declaration references). The ExportQuery::query_ref uses exact Id matching (symbol + syntax context), so it fails to find the export entry which was recorded with a different syntax context from the first namespace.

Previous Fix Attempt (January 29)

A previous fix was attempted on branch claude/issue-11514-20260129-0956 that added:

1. A secondary map export_by_sym: FxHashMap<Atom, Id> mapping just symbol names to namespace IDs
2. A fallback lookup that matches by symbol name alone when the identifier has unresolved context

This approach was sound but apparently the PR was never merged.

Proposed Solution

Given the recent TypeScript team clarification that tsc continues to produce correct output (even though tsgo doesn't), SWC should follow tsc's behavior and fix this issue. The previous fix approach is correct:

1. Add a secondary lookup map export_by_sym that maps export symbol names to their namespace IDs (for exports that are inside namespaces)
2. Modify ExportQuery::query_ref to fall back to symbol-only lookup when the identifier has unresolved syntax context
3. This correctly handles references to exports from merged namespace declarations

The fix is already implemented on branch claude/issue-11514-20260129-0956 (commit 4f09e3c71c).

Recommendation

Since the fix already exists, you can:

1. Cherry-pick or merge the existing fix from claude/issue-11514-20260129-0956
2. Or create a new PR based on that branch

Create PR from previous branch

--- • claude/issue-11514-20260129-0956