"The inferred type of X cannot be named without a reference to Y" (TS2742) occurs when multiple modules with the same package ID are resolved

[renke]

Bug Report

🔎 Search Terms

• TS2742
• cannot be named without a reference

🕗 Version & Regression Information

Problems occurs with 4.5.x and 4.6.x and most likely earlier versions (I've tried a few other versions). It stills occurs on 4.7.0-dev.20220321.

⏯ Playground Link

I've created minimal repository that shows the problem: https://github.com/renke/typescript-package-id-merge-repro

The problem occurs when using pnpm (due to the modules layout it uses). No problems occur when using npm/yarn.

To reproduce the problem run pnpm install and then ~~pnpm check~~ pnpx tsc -b.

💻 Code

I don't think the code itself matters to much except from the fact that it in fact does not have explicit type annotations (which is kind of the idea when using zod and by extension @renke/vommer).

import { vod } from "@renke/vommer";
import { z } from "zod";

export const UserId = vod("UserId", z.string());

export type UserId = z.infer<typeof UserId>;

export const Email = vod("Email", z.string().min(0));

export type Email = z.infer<typeof Email>;

export const User = vod(
  "User",
  z.object({
    id: UserId,
    email: Email,
  })
);

export type User = z.infer<typeof User>;

🙁 Actual behavior

The following error occurs when trying to build a composite TypeScript project (same happens when just using declaration: true).

The inferred type of 'User' cannot be named without a reference to '.pnpm/@[email protected]/node_modules/@renke/vo'. This is likely not portable. A type annotation is necessary.

The dependency tree of @renke/vommer

@renke/vommer 0.2.0
├── @renke/vo 0.2.0
└─┬ @renke/vod 0.2.0
  └── @renke/vo 0.2.0

Looking at the resolution trace TypeScript tries to resolve @renke/vo two times the first time from @renke/vommer and the second time from @renke/vod. Both end up having the package ID @renke/vo/dist/[email protected].

Using "preserveSymlinks": true doesn't solve the problem in so far that the error disappears but the type is inferred as any, because the dependencies of @renke/vommer are not found. Also I don't actually want to use it.

🙂 Expected behavior

The error should not occur when there are two (or more) modules that have the same resolved package ID. It would make sense for the error to occur when they have different versions.

[zengguirong]

same problem

[renke]

So, aside from finding a solution to this problem, is my assumption correct that having multiple packages with typings that have the same version should not cause any problems?

I'd also appreciate any hints on where to look at the source code to solve this problem.

[dohooo]

same problem!

[quadristan]

@renke i have a repro where everything has the same version here : https://github.com/quadristan/ts-indirect-type-reference-bug

[agmitron]

same problem :( have you solved it?

[renke]

I haven't solved it yet, but there is also a similar issue https://github.com/microsoft/TypeScript/issues/48212 with a milestone of TypeScript 4.8.0. Let's hope it will be solved soon.

[StarHosea]

same problem

[kiastorm]

I got this issue because the mentioned dependency had this code in its index.d.ts:

declare module 'react' {
  interface DOMAttributes<T> {
    css?: InterpolationWithTheme<any>
  }
}

and the file it was complaining in was using React.HTMLAttributes<HTMLElement> which references React.DOMAttributes. I worked around this issue by omitting the declared properties Omit<React.HTMLAttribute<HTMLElement>, "css">

[Peroconino]

Same problem :(

[vaibhavkumar-sf]

Same Problem for me too :(

[ivanbanov]

is there any expected timeline for a fix for this problem?

[grmkris]

same here

[patroza]

@RyanCavanaugh

[yingpengsha]

Same problem :(

[Evertt]

same here

[xlboy]

same here

[shellscape]

What's worse is that neither // @ts-ignore nor // @ts-expect-error will allow us to ignore the incorrect error. This is a pretty gnarly bug.

[mrmeku]

This bug occurs pretty readily when using pnpm since the node_modules directory layout is different under pnpm than npm/yarn. Any npm package whose types reference another npm package's type will generate the error

I've made a minimal reproduction here: https://github.com/mrmeku/portable_types_repro

[shellscape]

I've been deep-diving the issues related to this error and symlinks and pnpm specifically. Since 2019 it appears that this regression is reintroduced at least twice for each major version. That would suggest that tests are not sufficient for the case, nor to catch the regression.

[quadristan]

I have a repro + a workaround/solution here

https://github.com/quadristan/ts-indirect-type-reference-bug

tl-dr:

import type {} from "Y"; // or whatever Y really refers to

[i7eo]

I have a repro + a workaround/solution here

https://github.com/quadristan/ts-indirect-type-reference-bug

tl-dr:

import type {} from "Y"; // or whatever Y really refers to

Nice job! This is by far the best practice.👍

[RyanCavanaugh]

I've been deep-diving the issues related to this error and symlinks and pnpm specifically. Since 2019 it appears that this regression is reintroduced at least twice for each major version. That would suggest that tests are not sufficient for the case, nor to catch the regression.

The reason you see a history of this "regressing" at each version is that pnpm patches TypeScript when you install it, so every time TS updates, there's a few days where it appears to not work because pnpm hasn't updated their patching code yet.

[RIP21]

@RyanCavanaugh really? Do PNPM is patching TS in order for it to be compatible each and every time it installs it? That's a huge surprise for me really. Feels very unsustainable and kinda scary. Why is TSC itself is not compatible with PNPM? I hear about the first time in my life and never saw anything like that in the PNPM change log (not that I reading them (aside from major releases)) :)

[shellscape]

I've been deep-diving the issues related to this error and symlinks and pnpm specifically. Since 2019 it appears that this regression is reintroduced at least twice for each major version. That would suggest that tests are not sufficient for the case, nor to catch the regression.

The reason you see a history of this "regressing" at each version is that pnpm patches TypeScript when you install it, so every time TS updates, there's a few days where it appears to not work because pnpm hasn't updated their patching code yet.

could you point me at the code responsible for that? I'm a core contributor to PNPM and this is the first time I'm hearing of it. not to say that I disagree with you or that it isn't true, I'm just unaware of that.

[RyanCavanaugh]

Sorry, you're right. I've misconfused this with yarn.

[RyanCavanaugh]

@shellscape while I've got you here, we've been trying to reach security@ pnpm.io regarding an issue we identified a while back, but haven't received a reply. Can you poke the appropriate folks to take a look?

[shellscape]

sure thing. feel free to DM me info on twitter as well.

[aabccd021]

In my case the error looks like this

The inferred type of 'Foo' cannot be named without a reference to '.pnpm/@[email protected]_.../node_modules/@morphic-ts/model-algebras/lib/types'. This is likely not portable. A type annotation is necessary

The type definition wasn't exported from root of the package but it was from/lib/types.

So instead of just importing the package:

import type {} from '@morphic-ts/model-algebras'

I had to specify the path which the type definition was exported:

import type {} from '@morphic-ts/model-algebras/lib/types'

[matthew-dean]

@quadristan

You saved my life! I added:

import type {} from 'react'

This is definitely a super-nasty TypeScript bug. One of the worst I've encountered because it can't be ignored and, in this case, took me hours to debug and find this solution.

[CarlRibbegaardh]

import type {} from "Y"

Oooh! Thank you so much!! And this can be done in the root index.ts or anywhere really. So good. 😄