Fix named export aliases merging with `export =` by andrewbranch · Pull Request #3157 · microsoft/typescript-go

andrewbranch · 2026-03-19T00:28:58Z

#2946 seemed to miss resolving aliases in collecting symbol flags in a couple places, leading to missing errors on some things that aren't supposed to work, and some things that are supposed to work (I guess) silently failing:

class Foo {}
class Bar {}
export = Foo;
export { Bar }; // was missing error because `Bar` here is SymbolFlagsAlias, not SymbolFlagsValue

import { SomeTypeAlias } from "./t";
class Foo {}
export = Foo;
export { SomeTypeAlias }; // should ideally work, but didn't work and didn't error!

Copilot

Pull request overview

Fixes CommonJS export = module export checking/resolution so named export aliases are handled correctly, aligning the Go checker’s behavior with the intended TypeScript semantics (and the #2946 export-assignment merging work).

Changes:

Resolve alias targets when determining whether an export = module also exports value members (so TS2309 is correctly produced).
When importing from an export = module, look up supplemental type/namespace exports on the original module symbol (so named exports can resolve).
Add compiler test cases + reference baselines for the two reported scenarios (value export should error; type-only export should resolve).

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
`internal/checker/checker.go`	Updates alias-aware symbol-flag checks and adjusts export container selection for `export =` modules.
`testdata/tests/cases/compiler/exportAssignmentMerging7.ts`	New repro: `export =` plus named value export alias should produce TS2309 + downstream import error.
`testdata/tests/cases/compiler/exportAssignmentMerging8.ts`	New repro: `export =` plus named type alias export should be importable without error.
`testdata/baselines/reference/compiler/exportAssignmentMerging7.types`	Reference types baseline for test 7.
`testdata/baselines/reference/compiler/exportAssignmentMerging7.symbols`	Reference symbols baseline for test 7.
`testdata/baselines/reference/compiler/exportAssignmentMerging7.js`	Reference JS/d.ts baseline for test 7.
`testdata/baselines/reference/compiler/exportAssignmentMerging7.errors.txt`	Reference error baseline for test 7 (TS2309/TS2305).
`testdata/baselines/reference/compiler/exportAssignmentMerging8.types`	Reference types baseline for test 8.
`testdata/baselines/reference/compiler/exportAssignmentMerging8.symbols`	Reference symbols baseline for test 8.
`testdata/baselines/reference/compiler/exportAssignmentMerging8.js`	Reference JS/d.ts baseline for test 8.

You can also share your feedback on Copilot code review. Take the survey.

testdata/tests/cases/compiler/exportAssignmentMerging7.ts

testdata/tests/cases/compiler/exportAssignmentMerging8.ts

andrewbranch · 2026-03-19T15:00:27Z

internal/checker/checker.go

 	// A CommonJS module defined by an 'export=' might also export typedefs, stored on the original module
 	if originalModule != nil && len(originalModule.Exports) > 1 {
 		for _, symbol := range originalModule.Exports {
-			if symbol.Flags&ast.SymbolFlagsType != 0 && symbol.Name != ast.InternalSymbolNameExportEquals && exports[symbol.Name] == nil {
+			flags := c.getSymbolFlags(symbol)
+			if symbol.Name != ast.InternalSymbolNameExportEquals &&
+				flags&(ast.SymbolFlagsType|ast.SymbolFlagsNamespace) != 0 &&
+				flags&ast.SymbolFlagsValue == 0 &&


This combo of symbol flags was a Copilot contribution but I think it's right/desirable—we generally want to allow uninstantiated namespaces wherever we allow types. The comment was already talking about a narrower case than what was allowed, but reflects the motivation for the feature, not the breadth of all possibilities.

andrewbranch · 2026-03-19T14:57:32Z

internal/checker/checker.go

 	for _, symbol := range moduleSymbol.Exports {
-		if symbol.Name != ast.InternalSymbolNameExportEquals && symbol.Flags&kind != 0 {
+		if symbol.Name != ast.InternalSymbolNameExportEquals && c.getSymbolFlags(symbol)&kind != 0 {
 			return true
 		}
 	}


No, type-only export aliases do have value meanings even if they can't be used in emitting positions; this is working as designed.

andrewbranch · 2026-03-19T14:58:22Z

internal/checker/checker.go

+			flags := c.getSymbolFlags(symbol)
+			if symbol.Name != ast.InternalSymbolNameExportEquals &&
+				flags&(ast.SymbolFlagsType|ast.SymbolFlagsNamespace) != 0 &&
+				flags&ast.SymbolFlagsValue == 0 &&
+				exports[symbol.Name] == nil {


Again, correct observation, but working as designed.

jakebailey · 2026-03-19T03:09:52Z

testdata/baselines/reference/compiler/exportAssignmentMerging7.errors.txt

+    ~~~~~~~~~~~~~
+!!! error TS2309: An export assignment cannot be used in a module with other exported elements.
+    export { Bar }; // Causes error
+==== b.ts (1 errors) ====
+    import { Bar } from "./a";
+             ~~~
+!!! error TS2305: Module '"./a"' has no exported member 'Bar'.
+    const b = new Bar();


I wish we could solve this somehow by erroring but still constructing some sort of export that would make it work in skipLibCheck'd files...

andrewbranch · 2026-03-19T15:10:48Z

Hey look, a diff was deleted!

ahejlsberg

Approved with the suggested change.

ahejlsberg · 2026-03-19T20:59:13Z

internal/checker/checker.go

 		for _, symbol := range originalModule.Exports {
-			if symbol.Flags&ast.SymbolFlagsType != 0 && symbol.Name != ast.InternalSymbolNameExportEquals && exports[symbol.Name] == nil {
+			flags := c.getSymbolFlags(symbol)
+			if symbol.Name != ast.InternalSymbolNameExportEquals &&


Maybe compute flags after you check for ast.InternalSymbolNameExportEquals, just to not spend time computing something you're going to throw away.

andrewbranch added 2 commits March 18, 2026 16:50

Add tests for export assignment merging scenarios

e304e87

Refactor getExportsOfModuleWorker to simplify alias resolution logic

89f6b3c

Copilot AI review requested due to automatic review settings March 19, 2026 00:29

Copilot AI reviewed Mar 19, 2026

View reviewed changes

jakebailey reviewed Mar 19, 2026

View reviewed changes

andrewbranch added 2 commits March 19, 2026 08:05

Merge remote-tracking branch 'upstream/main' into copilot/steep-sloth

8dad238

Update baselines

c67f253

andrewbranch requested a review from ahejlsberg March 19, 2026 15:12

ahejlsberg approved these changes Mar 19, 2026

View reviewed changes

Don’t compute flags for ignored symbol table entries

f3a8b27

andrewbranch requested review from ahejlsberg and jakebailey March 20, 2026 20:05

jakebailey approved these changes Mar 20, 2026

View reviewed changes

andrewbranch added this pull request to the merge queue Mar 20, 2026

Merged via the queue into microsoft:main with commit 418d206 Mar 20, 2026
21 checks passed

andrewbranch deleted the copilot/steep-sloth branch March 20, 2026 21:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix named export aliases merging with `export =`#3157

Fix named export aliases merging with `export =`#3157
andrewbranch merged 5 commits intomicrosoft:mainfrom
andrewbranch:copilot/steep-sloth

andrewbranch commented Mar 19, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

andrewbranch Mar 19, 2026

Uh oh!

andrewbranch Mar 19, 2026

Uh oh!

andrewbranch Mar 19, 2026

Uh oh!

jakebailey Mar 19, 2026

Uh oh!

andrewbranch commented Mar 19, 2026

Uh oh!

ahejlsberg left a comment

Uh oh!

ahejlsberg Mar 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

andrewbranch commented Mar 19, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

andrewbranch Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

andrewbranch Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

andrewbranch Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

jakebailey Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

andrewbranch commented Mar 19, 2026

Uh oh!

ahejlsberg left a comment

Choose a reason for hiding this comment

Uh oh!

ahejlsberg Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants