tsgo fails to resolve namespace symbols in non-extends contexts across files
🧾 Environment
npx tsgo -v Version 7.0.0-dev.20250526.1
🧠 Summary
tsgo correctly handles extends A in a namespace context (as fixed in PR #66), but still fails to resolve namespace-scoped symbols like A, Afunc across files in other contexts such as:
- function return types
- constructor calls
- parameter types
- direct function calls
This leads to incorrect JavaScript output and runtime errors.
✅ Expected Behavior
All references to A and Afunc should be qualified as game.A and game.Afunc, matching how tsc behaves.
🔬 Minimal Reproduction
a.ts
namespace game {
export class A {
func() {
console.log('A.func');
}
}
export function Afunc() {
console.log('Afunc');
}
}
#### b.ts
namespace game {
export class B extends A {
override func() {
console.log('B.func');
}
}
Afunc();
}
#### b.js compiled by tsgo
var game;
(function (game) {
class B extends A { // expect game.A
func() {
console.log('B.func');
}
}
game.B = B;
Afunc(); // expect game.Afunc
})(game || (game = {}));
This is an intentional divergence. This sort of global analysis is problematic because it means that the emitted code for one file requires analyzing all other files (and therefore, no parallelism in emit).
We're expecting you to explicitly access the namespace a game.Afunc instead of relying on that analysis.
I assume we emit an error in b.ts, correct?
Thanks for the clarification!
I understand and respect the intentional divergence from tsc behavior for performance reasons.
However, I’d like to suggest: if tsgo doesn't support cross-file namespace symbol merging, could this be explicitly reported as a compiler error or editor diagnostic?
Currently, it silently compiles incorrect code, which can lead to runtime issues that are hard to detect. For large codebases migrating from tsc, this can be especially dangerous.
Even just surfacing it in the editor (e.g. via VSCode diagnostics) would be very helpful.
Thanks again for the great work!
It's definitely supposed to report an error.