Skip to content

"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 #47663

Closed
Closed
"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#47663
Assignees
weswigham
Labels
Needs InvestigationThis issue needs a team member to investigate its status.
Milestone
TypeScript 5.5.0

Description

@renke
Renke Grunwald (renke)
opened on Jan 30, 2022

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/@renke+vo@0.2.0/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/index.d.ts@0.2.0.

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.

Activity

  1. zengguirong commented on Feb 9, 2022

    @zengguirong
    zengguirong
    on Feb 9, 2022

    same problem

  2. Ryan Cavanaugh (RyanCavanaugh)
    added
    Needs InvestigationThis issue needs a team member to investigate its status.
    on Feb 10, 2022
  3. Ryan Cavanaugh (RyanCavanaugh)
    added this to the Backlog milestone on Feb 10, 2022

  4. renke commented on Mar 16, 2022

    @renke
    Renke Grunwald (renke)
    on Mar 16, 2022
    Author

    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.

  5. dohooo commented on Apr 24, 2022

    @dohooo
    Caspian 東澔 (dohooo)
    on Apr 24, 2022

    same problem!

  6. quadristan commented on May 23, 2022

    @quadristan
    Tristan P. (quadristan)
    on May 23, 2022

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

  7. agmitron commented on Jul 10, 2022

    @agmitron
    Aleksei Gmitron (agmitron)
    on Jul 10, 2022

    same problem :( have you solved it?

  8. renke commented on Jul 15, 2022

    @renke
    Renke Grunwald (renke)
    on Jul 15, 2022
    Author

    I haven't solved it yet, but there is also a similar issue #48212 with a milestone of TypeScript 4.8.0. Let's hope it will be solved soon.

  9. StarHosea commented on Aug 8, 2022

    @StarHosea
    StarHosea
    on Aug 8, 2022

    same problem

  10. kiastorm commented on Aug 24, 2022

    @kiastorm
    kia (kiastorm)
    on Aug 24, 2022

    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">

  11. Peroconino commented on Aug 26, 2022

    @Peroconino
    Leandro Fontellas Laurito (Peroconino)
    on Aug 26, 2022

    Same problem :(

  12. vaibhavkumar-sf commented on Sep 2, 2022

    @vaibhavkumar-sf
    vaibhavkumar-sf
    on Sep 2, 2022

    Same Problem for me too :(

  13. ivanbanov commented on Sep 12, 2022

    @ivanbanov
    Ivan Banov (ivanbanov)
    on Sep 12, 2022

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

  14. grmkris commented on Sep 15, 2022

    @grmkris
    Kris (grmkris)
    on Sep 15, 2022

    same here

  15. patroza commented on Sep 16, 2022

    @patroza
    Patrick Roza (patroza)
    on Sep 16, 2022

    Ryan Cavanaugh (@RyanCavanaugh)

  16. 100 remaining items

  17. Dorianslavov commented on Feb 23, 2024

    @Dorianslavov
    Dorian (Dorianslavov)
    on Feb 23, 2024

    I have managed to make the error go away by making a TypeScript Reference Type at the top of the file

    In my case I was was importing useI18n function and spreading an object in it's parameter object like
    useI18n({ ...someObj })

    which caused this

    The inferred type of useI18n cannot be named without a reference to .pnpm/@intlify+core-base@9.9.0/node_modules/@intlify/core-base . This is likely not portable. A type annotation is necessary.

    ✅ Fixed it by doing this

    At the top of the file which used useI18n I've added the TS reference type like so

    /// <reference types="@intlify/core-base" />

    So to fix it, basically check the problematic package name ( in my case it was @intlify/core-base ) and add it as a TypeScript Reference Type like in the example above

  18. Ryan Cavanaugh (RyanCavanaugh)
    assigned
    Wesley Wigham (weswigham)
    on Feb 23, 2024
  19. Ryan Cavanaugh (RyanCavanaugh)
    modified the milestones: Backlog, TypeScript 5.5.0 on Feb 23, 2024

  20. LOWE-7566 commented on Mar 29, 2024

    @LOWE-7566
    LOWE-7566
    on Mar 29, 2024

    use type casting it is always solved in that way

  21. matheo commented on Mar 31, 2024

    @matheo
    Mateo Tibaquirá (matheo)
    on Mar 31, 2024
    import type {} from "Y";

    This didn't work for my Nx monorepo with pnpm because in the workspace, peer dependencies were installed inside the library folder duplicating the package and causing the error. I opted to disable the peerdeps installation with:

    .npmrc
auto-install-peers=false

    and reviewed the peer dependencies warnings to confirm that they were installed, and added the ones missing: then I confirmed that everything ran as expected.

  22. anyesu
    added a commit that references this issue on Apr 1, 2024

    fix: 🐛 update `tsconfig.json`

    219ae6a
  23. Liran Cohen (LiranCohen)
    added 3 commits that reference this issue on May 2, 2024

    add reference types from dwn-sdk-js to avoid pnpm build error https:/…

    8cc806f

    add reference types from dwn-sdk-js to avoid pnpm build error https:/…

    44ab75b

    add reference types from dwn-sdk-js to avoid pnpm build error (#507)

    d863c37

  24. patricktree commented on May 4, 2024

    @patricktree
    Patrick Kerschbaum (patricktree)
    on May 4, 2024

    FYI there is some interesting discussion on this topic in microsoft/TypeScript#58176.

    I find this idea for a solution by Sebastian "Sebbie" Silbermann (@eps1lon) interesting (which is kind of bringing workaround #3.1 of my comment above into tsc itself):

    Is there an option to enforce that whatever getMakeSubDep returns, is also exported from other_package? Then TypeScript could reference those exports instead. It should already do that today if you explicitly export the return type. But TypeScript favors import('sub_dep').Options over import('other_package').Options even if other_package explicitly exports Options.

  25. cumt-robin commented on May 4, 2024

    @cumt-robin
    程序员白彬 (cumt-robin)
    on May 4, 2024 via email

  26. RyanCavanaugh commented on May 6, 2024

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on May 6, 2024
    Member

    Closing per #42873 (comment)

  27. Ryan Cavanaugh (RyanCavanaugh)
    closed this as completedon May 6, 2024
  28. microsoft
    locked as resolved and limited conversation to collaborators on May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Needs InvestigationThis issue needs a team member to investigate its status.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions