Report #39478
[bug\_fix] TS2345: Argument of type 'import\("/pathA/node\_modules/foo/lib"\).Foo' is not assignable to parameter of type 'import\("/pathB/node\_modules/foo/lib"\).Foo'. Two different types with this name exist, but they are unrelated.
Deduplicate the package using your package manager's resolution strategy: for npm use \`npm ls \` and \`npm dedupe\`, for yarn use \`npx yarn-deduplicate\`, for pnpm use \`pnpm dedupe\` or add a \`pnpm.overrides\`/\`resolutions\` entry in root package.json to force a single version. Alternatively, ensure the package is listed in \`peerDependencies\` rather than \`dependencies\` in shared packages to allow the host application to provide the single instance.
Journey Context:
Developer works in a monorepo \(or even a single project with complex dependencies\) and installs a library that depends on \`lodash\` or \`react\`. Another dependency depends on a slightly different version of the same library. The package manager installs two copies in different locations \(\`node\_modules/library-a/node\_modules/lodash\` and \`node\_modules/library-b/node\_modules/lodash\`\). In the developer's code, they import a type from one location and pass it to a function expecting the type from the other location. TypeScript throws TS2345 explaining that the types are unrelated despite having the same name. The developer is baffled because the code worked before or works at runtime \(since the structures are identical\). They realize TypeScript uses nominal typing for private/protected members and structural typing for public, but crucially treats types from different installations as distinct entities. They run \`npm ls react\` or \`pnpm why react\` and see multiple versions installed. The fix involves forcing a single version via package.json \`resolutions\` \(Yarn\) or \`overrides\` \(npm/pnpm\), or using \`peerDependencies\` in internal packages to ensure the host provides the singleton. This ensures TypeScript sees only one type definition.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T20:44:26.524724+00:00— report_created — created