Module resolution: Module resolved to indirect dependency rather than direct local one when versions are the same

[grigasp]

🔎 Search Terms

"local module resolution", "module resolution same version"

🕗 Version & Regression Information

• Noticed in 5.6.3, also reproduced with next, 4.6, 4.8, 5.0.
• I reviewed the FAQ for entries including "resol".

⏯ Playground Link

https://github.com/grigasp/ts-deps-issue

💻 Code

Package [email protected] is released with the following:

export type A1 = number;

Locally we have this package at the same version, but with an additional type:

export type A1 = number;
export type A2 = string;

Locally we also have a package b, that has a dependency on a released version of [email protected] and exports the following type:

import { A1 } from "a";
export type B = A1;

Finally, locally we also have a package c, that has dependencies on local workspace versions of packages b and a and imports types from them both:

// Switching order of these import fixes the build
import { B } from "b";
import { A2 } from "a";

const b: B = 1;
const a2: A2 = "a2";

🙁 Actual behavior

When building package c, the build fails with error:

> [email protected] build
> tsc

src/index.ts:3:10 - error TS2305: Module '"a"' has no exported member 'A2'.

3 import { A2 } from "a";

🙂 Expected behavior

When building package c, TypeScript resolves package a to our local version which does have the A2 type, and the build succeeds.

Additional information about the issue

I tried running tsc -traceResolution for package c and it seems that both - released package and the local one - are assigned the same Package ID:

...
======== Resolving module 'a' from 'E:/temp/ts-deps-issue/packages/c/src/index.ts'. ========
...
======== Module name 'a' was successfully resolved to 'E:/temp/ts-deps-issue/packages/a/lib/index.d.ts' with Package ID 'a/lib/[email protected]'. ========

======== Resolving module 'a' from 'E:/temp/ts-deps-issue/packages/b/lib/index.d.ts'. ========
...
======== Module name 'a' was successfully resolved to 'E:/temp/ts-deps-issue/node_modules/.pnpm/a@file+packages+a+a-1.0.0.tgz/node_modules/a/lib/index.d.ts' with Package ID 'a/lib/[email protected]'. ========
...

I suppose that could cause a cache collision or something like that.

[andrewbranch]

I suppose that could cause a cache collision or something like that.

Exactly; we deduplicate packages by name and version; a different symptom of the same cause was closed as a design limitation here: #51976. I’m not sure what we could do about this.

[grigasp]

I suppose that could cause a cache collision or something like that.

Exactly; we deduplicate packages by name and version; a different symptom of the same cause was closed as a design limitation here: #51976. I’m not sure what we could do about this.

Just throwing out a couple of ideas...

• Could you use full path to the module for package id? So instead of a/lib/[email protected], it would be E:/temp/ts-deps-issue/packages/a/lib/index.d.ts or E:/temp/ts-deps-issue/node_modules/.pnpm/a@file+packages+a+a-1.0.0.tgz/node_modules/a/lib/index.d.ts.

• Could you detect that the module is from a workspace package and for such packages use a special version identifier, e.g. a/lib/index.d.ts@workspace?

[andrewbranch]

We deduplicate packages for a reason, so defeating the deduplication is just trading one problem for another. Including the same code multiple times can cause bogus errors. While it would fix your specific use case here, it could just as easily create duplicate declaration errors for someone else.

[grigasp]

We deduplicate packages for a reason, so defeating the deduplication is just trading one problem for another. Including the same code multiple times can cause bogus errors. While it would fix your specific use case here, it could just as easily create duplicate declaration errors for someone else.

Isn't it the job of package manager to do that?

If a package is unintentionally duplicated, then there can be many more problems than just duplicate declarations. To name a few that quickly come to mind: instanceof checks, Symbol, global state. Deduplication on TS side will hide all that. IMO, all that should be left up to package manager and if it decides to duplicate a package, then it's either intentional, or a problem with dependencies setup, in which case I'd rather get an error at build time rather than run time.

[RyanCavanaugh]

Isn't it the job of package manager to do that?

This hasn't always been the case; older versions of npm would not deduplicate when sub-dependencies needed to be nested, and it's a huge performance problem for TS if we need to e.g. resolve 30 copies of [email protected] in different subfolders.

You can argue that an ideally set-up package manager wouldn't do this, but I'd also argue that a correctly set-up package manager can't produce two packages with the same version and the same name but with different contents, which is the setup your repro depends on. It doesn't really fly to say we should rely on one invariant while ignoring the other.

[typescript-bot]

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