Exported types in an ESM namespace are not "nameable" (have repro)

[jasonkuhrt]

🔎 Search Terms

inference
"type cannot be named"
"package exports"

🕗 Version & Regression Information

I don't know if this is a bug or a feature request. The behaviour seems wrong to me but I am not aware of a reference/documentation actually stating how its supposed to work so...

⏯ Playground Link

https://github.com/jasonkuhrt/repro-ts-lib-types-reference

💻 Code

Check the repo as the scenario spans multiple modules and packages to reproduce.

🙁 Actual behavior

In short I expect that as a library author types exported like as follows will be "nameable" in inference cases in downstream consumer code:

Library Package:

// index.ts
export * as Bar from './bar.ts

// bar.ts
export interface A {}

Project Package:

// main.ts
import * as Thing from './thing.js'
import * as Resources from './resources.js'

const thing = Thing.create(Resources.A)
//    ^^^^^ "... cannot be named ..." error

// thing.ts
export create = <t>(t:t)=>t

// resources.ts
import { Bar } from 'library-package'
declare const A: Bar.A

🙂 Expected behavior

I expect thing to infer to Bar.A just fine.

Additional information about the issue

Really curious about this one!

[RyanCavanaugh]

https://github.com/Microsoft/TypeScript/wiki/FAQ#the-inferred-type-of-x-cannot-be-named-without-a-reference-to-y-this-is-likely-not-portable-a-type-annotation-is-necessary

The key constraint here is that the declaration emit phase can't do novel module resolution, so will only ever output module specifiers that have already been resolved as part of the earlier phase of compilation.

The "working" cases in resource.ts cause different behavior because resolving those imports lets TS realize that those portable paths (ones that don't require ../ing out of your local project) are ones that can be used to refer to A. In the non-working case, TS never sees a portable path that can be used to refer to A in main, and has no choice but to error.

[typescript-bot]

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

[jasonkuhrt]

@RyanCavanaugh thanks for the explanation, I am gong to return to re-read that a few times to try and understand.

In the example in the FAQ it talks about a transient dep scenario, however in my case I am only talking about a direct dep whose types are behind an ESM namespace.

I don't see it clearly spelled out that TS cannot follow types exported within an ESM namespace. And since TS does support following types exported within a TS namespace, I find the difference surprising.

Maybe what you're saying above (and/or the docs you link to) are implicating that ESM namespaces would not work either, and I am just so far missing the logical inference.

[RyanCavanaugh]

This is admittedly very arcane. Let me try again and maybe we can collab to get something for the FAQ.

During the program creation phase we take all your imports and follow them to figure out which files they resolve to. So you'd have something like

// src/pkg1/foo.ts
import * as x from "somepkg/subpath"

We resolve somepkg/subpath and find that it's at the relative path ../somepkg/subpath.d.ts. At this point, any time we need to refer to a type that originates in that file, we know it's safe to refer to it by the somepkg/subpath specifier in this location

However, somepkg/subpath has a re-export:

// ../somepkg/subpath.d.ts
export y from "./otherpath"

This resolves to ../somepkg/otherpath.d.ts.

Critical: at this point we have never used the name somepkg/otherpath to refer to ../somepkg/otherpath.d.ts

After program creation, we do some other stuff and go to the declaration emit phase. It becomes time to emit some synthesized imports to refer to some inferred types.

If we're emitting a reference to a type from ../somepkg/subpath.d.ts, it's been shown that (in this file context), it's legal to refer to it by somepkg/subpath

If we're emitting a reference to type from ../somepkg/otherpath.d.ts, we've only ever seen this referred to by the path ./otherpath, and the computed relative path from the current file to that file goes outside of the current package's scope, and is thus not portable. We don't know that it'd be legal to say somepkg/otherpath here, because that resolution never occurred during program creation.

This is a sort of architectural constraint - all module resolution must occur upfront - but it's also in general not obviously computable: given the complexity of export maps, import maps, and other misc config, the set of names that could work here is more or less unbounded in the worst case, and there's potentially multiple names that might work. So while this might be tractable in some easier cases, it's not an avoidable problem in all or even most configurations.

[jasonkuhrt]

Super interesting and thanks for taking the time.

Trying to wrap my head around the algorithm/rules of TS for synthesizing imports of inferred types.

If somepkg exports the types in module otherpath in ANY entrypoint module listed in package.export then TS will be able to synthesize imports for inferred types coming from otherpath. IIRC this is one of the things my repro repo shows. E.g.:

// whatever.ts, a package entry point
export * from "./path/to/otherpath"

If however somepkgwere to export otherpath like so:

// whatever.ts, a package entry point
export * as X from "./path/to/otherpath"

Then TS will not "discover" the type to be able to synthesize imports of it.

I suppose it's possible that a package entry point could have 1000 nested ESM namespaces, and one could ask what then? Why should TS traverse one level of ESM namespace but not 1000? And I also imagine the cost of searching namespaces could be very high, e.g exposing a huge tree of types where only one needle in the haystack is the type we need to synthesize.

Still, ESM namespaces seem like a robust solid construct. Is there not a path here for TS to take that honours a strict interpretation of the ESM spec and does traverse it? I totally agree TS should not support non standard or platform specific stuff (more then it has to, eg TS does do some stuff to help Node users out). But as far as I know, ESM is ECMA level stability and about as neutral and standard as it gets? At least my naive view of this landscape suggests so haha.

Thanks Ryan!