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

[yujiang]

---

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

[jakebailey]

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?

[yujiang]

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!

[jakebailey]

It's definitely supposed to report an error.

[dtscd]

This is also something I've encountered. I have a single file with multiple instances of the same namespace (it is joined together at this point), even within the same file, the namespaces are NOT correctly assigned and no error is given. So long as the namespace declarations are in the same file, would you be open to a PR to correct this?

[dtscd]

I've sent a PR #2597 that fixes this within the same file. It technically follows tsgo's design, while allowing an external system to arrange the files correctly in order for a single file output. The fix is small and it solves a real world problem with my project that is a large (2MB of typescript) project.

[jakebailey]

I believe our intent in 6.0 and 7.0 is to not do that, no?

• microsoft/TypeScript#54500
• [WIP] Disallow merging of enum declarations TypeScript#61262

[dtscd]

Yes, likely. I didn't realize the shadowing effect in ts6 or ts7 would be purposeful. In prior investigations (including this thread) the rational was always "cross file performance".

With this one change though it effectively completely breaks namespaces as an effective cross file organization tool and forces a rewrite into es modules.

If this statement stands:

In TypeScript 6.0, this behavior will be removed, and bar will refer to the outer const (or be a name resolution error if that variable isn't there).

Then I will need to figure out how I want to move forward. Because the patch to fix is tiny, perhaps I'll just carry it myself for the time being.

I would love for that decision to be more nuanced, where resolution within the same file will resolve, but will fail for namespaces in a different file.

[jakebailey]

breaks namespaces as an effective cross file organization tool

Where are you using this? We were only aware of ourselves doing this (until we switched to modules in TS 5.0), and outFile is deprecated already, and prepend was deprecated in 5.0 too. So, I'm not totally sure how you're making use of it today.

[dtscd]

I'm attempting to move from tsc to tsgo. Today I'm using outFile from tsc. I'm not using modules, but I am using namespaces. It was easy enough to write a topo sort on the src files and join them together, but when I used tsgo to compile from ts to js, I ran into this problem. I would prefer to use tsgo for speed and future facing emitting. I can stay with tsc for now and plan a migration to es modules. Though as a Go developer, I'm not fond of es modules. With this change I get a working compilation from tsgo as-is.

If this isn't going to change, it would be nice for tsgo to issue an error in situation like this. Currently tsgo is able to do the resolution when checking types, it just doesn't do the transformation. Part of the frustration comes from the half-way state: no errors emitted, capable of resolving symbol within namespaces in tsgo, but no final transformation (which is less then 10 lines long).

[jakebailey]

I think I said this above, but the missing errors are the major concern here.

Maybe we should go back and not change this, we're just in a weird state between the two. I'll bring this up with the team.