Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.

Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.

@microsoft-github-policy-service agree

Please let me know if there are any concerns with the approach, implementation, or tests. I’m happy to make adjustments based on feedback.

The emitter cannot depend on the type checker like this. It won't scale well for the Go port, and it also means it's impossible to replicate TS's emit externally without having a type checker, which does not exist outside of this project.

In general, I do not this approach is workable. The fix needs to come by some other means. The Printer should not contain logic like this.

I’ve revised this PR to follow the feedback .
The new implementation avoids using the type checker or emitter logic and instead handles explicit unique symbol annotations directly in declarations.ts.

I’ve tried to keep the change minimal and aligned with what was suggested.
If I’ve misunderstood or taken the wrong approach again, please let me know — I’m happy to adjust further.

Thank you for the feedback! I’ve gone through the issues raised and want to clarify the changes included in this commit:

Test files updated:
The test case tests/cases/compiler/uniqueSymbolReassignment.ts has been updated to reflect correct behavior and expected outputs. As a result, the baselines have been updated accordingly, and now include the following files in tests/baselines/reference/:

uniqueSymbolReassignment.js

uniqueSymbolReassignment.symbols

uniqueSymbolReassignment.types

These are the correct and intended baseline files for this test case. Other artifact files such as .d.ts, .d.errors.txt, and .d.types were removed because they were leftover artifacts from earlier runs and shouldn’t be tracked in the repository.

Fix in the test logic:
The original test used const declarations for non-unique symbols, which caused confusion in the emitted output and errors that did not align with the expected behavior. I corrected the declarations in the test to:

// Non-unique symbols (regular Symbol() without const)
let nonUniqueSymbol1 = Symbol('nonUnique1');
let nonUniqueSymbol2 = Symbol('nonUnique2');

By using let instead of const, the test now accurately reflects how non-unique symbols should behave, and the emitted output aligns with the correct TypeScript semantics.

Please let me know if further adjustments are needed or if any part of the test setup should be improved.

if I’ve misunderstood any part of the concerns raised or if further adjustments are needed, please let me know

Just wanted to follow up on this! Let me know if there’s anything needed from my side

I feel a little suspicious of this due to an example like this: Playground Link

const mySymbol = Symbol('Symbols.mySymbol');
const Symbols = {
    mySymbol
} as const;

function myFunction() {}

myFunction.mySymbol = Symbols.mySymbol;

export { myFunction, mySymbol };

We end up with two different unique symbol exports which don't work together.

But, I'm not sure if this is even new.

I feel somewhat weird about this PR in general though just because it's a syntactic rule, so I was trying to break it by having it emit at some point a typeof mySymbol (so, would evaluate to unique symbol without saying unique symbol, but could not get that to happen.)

Following the feedback on symbol identity and multiple exports, I’ve updated the declaration emission logic in this commit. Here’s what changed:

Export detection: Uses TypeScript’s collectExternalModuleInfo in declarations.ts to reliably detect which symbols are exported at the top level.

Correct typeof emission for exported unique symbols:
Namespace properties that are explicitly annotated unique symbol and exported now generate typeof <name> instead of just unique <name>, preserving symbol identity across multiple exports.

The changes only touch declarations.ts, without relying on the type checker or printer heuristics.

Consistent const emission: All changes remain focused on explicitly annotated unique symbol properties: when detected, they are always emitted as const in .d.ts files.

Please let me know if I misunderstood anything, or if you see any gaps or edge cases I should handle further.

Just wanted to check up if i overlooked something