typescript-go icon indicating copy to clipboard operation
typescript-go copied to clipboard

tsgo fails to resolve namespace symbols in non-extends contexts across files

Open yujiang opened this issue 7 months ago • 3 comments


🧾 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 = {}));

yujiang avatar May 28 '25 13:05 yujiang

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?

jakebailey avatar May 28 '25 16:05 jakebailey

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!

yujiang avatar May 29 '25 07:05 yujiang

It's definitely supposed to report an error.

jakebailey avatar May 29 '25 13:05 jakebailey