Import alias fails after being re-exported from another namespace via an export declaration when only import aliases are exported

[dsherret]

Bug Report

I found the using import Something = Namespace.Something then re-exporting that from a namespace leads to some strange behaviour, but only when import alises are the only things exported.

🔎 Search Terms

"Cannot use namespace" as value

🕗 Version & Regression Information

• This probably has existed for a while
• Tested in 5.2.0-dev.20230529

⏯ Playground Link

https://www.typescriptlang.org/play?ssl=24&ssc=86&pln=2&pc=3#code/CYUwxgNghgTiAEBbA9sArhBAXEBnL8A3gLABQ8SqGCADlGANYCMRZFFYyAdvvDvkwBc8fDACWXAOYBuNu048C-LAGZhXNIgBGIGLPLsQADxrIYBQnzxYmAGiv4V8AL76KzuSnSZ4dRgCZWAwoxRFNzBxt4AF5femYAOmUmN3ZQ8KVrJ1i-ROUVVIpjDKJIu0inVzkPAy9qOMYnEmD4dLNMgRiGhn8k6xS5ELD2iq7c3vzC+GKRy2T7fJdUmrk2iNyAURN2lhz4pj6BVLWCTe3zQL2Aw5tj4fX4rYzs7pUbgYMT7qf2gBYx+ITfr6OQKXj5YRYACeNBAyAAZt9zqpUjMIpYzhkWFBcGV7Jj2oEcZF-AssvjHsj-sTlP8qqRnEA

💻 Code

declare module pack1 {
  const test1: string;
  const test3: number;
  export { test1, test3 };
}
declare module pack2 {
  import test1 = pack1.test1;
  import test3 = pack1.test3;
  export { test1, test3 };
}
declare module pack3 {
  import test1 = pack2.test1;
  import test3 = pack2.test3;
  export { test1, test3 };
}

import packExport1 = pack1.test1;
import packExport2 = pack2.test1;
import packExport3 = pack3.test1;
import packExport4 = pack2.test1;

declare const test3: typeof packExport3;
export { packExport1 as test1, packExport2 as test2, test3, packExport4 as test4 };

🙁 Actual behavior

The types are inferred correctly, but the type checker errors:

> npx tsc test.d.ts
test.d.ts:12:18 - error TS2708: Cannot use namespace 'pack2' as a value.

12   import test1 = pack2.test1;
                    ~~~~~

test.d.ts:13:18 - error TS2708: Cannot use namespace 'pack2' as a value.

13   import test3 = pack2.test3;
                    ~~~~~

test.d.ts:18:22 - error TS2708: Cannot use namespace 'pack2' as a value.

18 import packExport2 = pack2.test1;
                        ~~~~~


Found 3 errors in the same file, starting at: test.d.ts:12

🙂 Expected behavior

No errors.

Workaround

Add some other declaration and export it from any namespace that only exports import aliases:

// no diagnostics, everything is fine now
declare namespace pack1 {
  const test1: string;
  const test3: number;
  export { test1, test3 };
}
declare namespace pack2 {
  import test1 = pack1.test1;
  import test3 = pack1.test3;
  export const __dummyExport: string; // edit: actually, i discovered this doesn't need to be exported
  export { test1, test3 };
}
declare namespace pack3 {
  import test1 = pack2.test1;
  import test3 = pack2.test3;
  export const __dummyExport: string;
  export { test1, test3 };
}

import packExport1 = pack1.test1;
import packExport2 = pack2.test1;
import packExport3 = pack3.test1;
import packExport4 = pack3.test3;

declare const test3: typeof packExport3;
export { packExport1 as test1, packExport2 as test2, test3, packExport4 as test4 };

Workaround 2

Use export import:

// no errors
declare namespace pack1 {
  const test1: string;
  const test3: number;
  export { test1, test3 };
}
declare namespace pack2 {
  export import test1 = pack1.test1;
  export import test3 = pack1.test3;
}
declare namespace pack3 {
  export import test1 = pack2.test1;
  export import test3 = pack2.test3;
}

import packExport1 = pack1.test1;
import packExport2 = pack2.test1;
import packExport3 = pack3.test1;
import packExport4 = pack3.test3;

declare const test3: typeof packExport3;
export { packExport1 as test1, packExport2 as test2, test3, packExport4 as test4 };

[andrewbranch]

I’m not sure what to do about this. I simplified the test case down to

declare module pack1 {
  const test1: string;
  export { test1 };
}
declare module pack2 {
  import test1 = pack1.test1;
  export { test1 };
}
export import test1 = pack2.test1;

Whether a namespace is considered instantiated (has a runtime representation) is decided syntactically by the binder. The rule that’s in place is that import ... never makes a namespace instantiated, export import ... always makes a namespace instantiated, and export { ... } only does if one of the things it exports can be determined to be valuey. We walk up from the export declaration until we find the definition of test1 at import test1 = pack1.test1, and we stop because that doesn’t count as valuey because there’s no export modifier. In this case, since everything is in the same source file, it’s possible that we could so better by walking up higher, but we don’t really want to use a rule that can’t be applied consistently between local imports and cross-file imports.

After reviewing the source code, I think this is a design limitation, and it’s also clear that the workaround that best represents the intention is export import. Maybe it would be worth adding a checker error when it discovers that an uninstantiated namespace actually exports a value via an alias.

Note that there’s no issue or inconsistency with emit, since export {} declarations aren’t allowed in non-ambient namespace declarations.

[andrewbranch]

Actually, it might make more sense to say that any re-export of an import alias should make the namespace count as instantiated. That might result in some false positives, but it makes as much sense as export import SomeType = mod.SomeType counting towards instantiation 🤷