Multiple `export as namespace` not merging in the same namespace

[lmartorella]

🔎 Search Terms

export as namespace, ambient namespace, module

🕗 Version & Regression Information

• This is the behavior in every version 5.x I tried, and I reviewed the FAQ for entries about "export as namespace" but I. didn't find anything relevant.

⏯ Playground Link

https://www.typescriptlang.org/dev/bug-workbench/?ts=5.8.3&multifile=true#code/PTAEAEDMEsBsFMB2BDAtvAXKW0BGBGAOgBNCAXAZwFgAoY+AY1mQCd5QBzWAe12VlABvWqFAp0FAA7IG7RBSEjRo+AA9J3FmVBNkFBQGF8Q0AF8l5mpbUatJy7RAQYCcZmx4ATCXLUa0VFtteVBIFm5UUAAiQmAcXG94ClQogG5aG01tPTE0JOlZMQp0mkytAF4ikscwKDgkPKx4xOSfSgz1LNB6XTYdZn1QA097WhrnercmvABmNr8AoKLQ8MiYuNnCJJSSsuyFNykZOWKOoMr5aponOtdGj1w57fmzrp7mPt1BgxnRmnHbg10FhkJJJL4amAADxsSDwNiIQrSMgAC3K63iRFIlCioGAAD5IaAYfA4QikchUejYs15riCUSSWSkBSqRjNtiKPTCf8aAxuPJtAxjBd4AB3IqEIwACgAlCV+YKdCNRRL5FLPHKFQKKELfqrJT8tbQgA

💻 Code

// @filename: lib1.d.ts
declare global {
  namespace ns {
     export class C1 { }
  }
}
export { }

// @filename: lib2.d.ts
import ns from "./lib2.esm";
export as namespace ns;
export= ns;

// @filename: lib2.esm.d.ts
export declare class C2 { }

// @filename: lib3.d.ts
import ns from "./lib3.esm";
export as namespace ns;
export= ns;

// @filename: lib3.esm.d.ts
export declare class C3 { }

// @filename: app.ts
/// <reference path="./lib1.d.ts" />
/// <reference path="./lib2.d.ts" />
/// <reference path="./lib3.d.ts" />

const c1 = new ns.C1();
const c2 = new ns.C2();
const c3 = new ns.C3();

🙁 Actual behavior

Property 'C3' does not exist on type 'typeof import("/lib2.esm")'.

Only the ambient module (lib1) and the first "export as namespace ns" instance (lib2) are merged in the target ambient namespace.
It doesn't find the symbols declared in lib3, or any other additional file that uses "export as namespace ns".

🙂 Expected behavior

All declaration files that uses "export as namespace ns" are expected to correctly merge in the same namespace, not only the first one.

Additional information about the issue

A very little documentation is around about the "export as namespace" feature.

We are converting our codebase migrating from ambient module to ESM, and we need to phase the migration one module at a time, still having the possibility to use the code as ambient until the full migration completes.

Even a different workaround is more than welcome!

[RyanCavanaugh]

If you're hand-authoring .d.ts files, you need to turn off skipLibCheck to validate your work. These files are full of errors.

The correct way to do this is to have one export as namespace declaration, and add to it via augmenting the module that declaration is it. See https://www.typescriptlang.org/docs/handbook/declaration-merging.html#module-augmentation

[lmartorella]

Yep, the sample was a minimal rough sample to replicate the issue.

Ok thanks. I was aware that augmenting a module requires re-exporting a different new module.

The documentation was not clear about the fact the export as namespace feature is affected / implemented with module augmentation.
https://www.typescriptlang.org/docs/handbook/declaration-files/templates/module-d-ts.html

So can you confirm that there are no other ways to progressively migrate a multi-part ambient-based library that merge in the same ambient namespace?
The plan was to migrate one chunk at a time to module as shippable increments, but this doesn't seems to have workaround, at least for what matter our public declaration files.
(E.g. in the above example, migrate lib1 to ESM and re-export in the main namespace using export as namespace to keep backward compatibility, then lib2, etc.. until all the libs are migrated).

Thx! L

[RyanCavanaugh]

In this situation I'd probably flip it around and have every file contribute to the global scope, then have one module declaration that exports the relevant global(s). There are trade-offs to either approach but those are basically the only two ways, yes.

[typescript-bot]

This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.