TypeScript: Package dependencies and The inferred type of ... cannot be named without a reference to ...

solved with Module resolution:

{
  "compilerOptions": {
    "baseUrl": ".", // This must be specified if "paths" is.
    "paths": {
      "graphql-compose": ["node_modules/graphql-compose/"]
    },
   // ...
}

Happens when we have conflicting versions of a package installed. A temporary solution would be to remove the package mentioned from peer dependencies of the plugin giving the error.

Or install the exact version of common dependancy

Try with:

{
  "compilerOptions": {
    "preserveSymlinks": true
  }
}

Credits to @imcuttle https://github.com/microsoft/TypeScript/issues/42873#issuecomment-1007540868

There are workarounds for this, though none of which I have liked. In my case, importing the package whose type was used and is considered “private” gets around this.

For example, if you had defined a type in package X called ExampleA that referenced type ExampleB in package Y, and it complained that it references private type ExampleB from node_modules/Y, you can do

import "Y";

This will, however, not work if you use that package only as a dev dependency.

A workaround would be to use import type but that does not allow side-effect imports (e.g. import type "Y" is not valid)

You could import the type that causes the issue, such as

import type { ExampleB } from "Y";

Again though, none of these are that pretty. I hope that a better solution can be proposed here because it makes more advanced types absolutely worthless or introduces ugly code with necessary comments pointing to this issue 😞

Same issue here. With Typescript 4.1.5.

I wonder why ist this still open, since it’s created on February 2019 😄

Hello, I had the same issue!

As a POC, I created a repository dedicated to this issue, to show how it is happening! Repository: https://github.com/nogueira7egend/ts-symlink-error/

Screenshot Error:

Please check it and follow the instructions that are on README! Best regards

Yep, just like everyone else is hinting, this problem happens when a dependency that is linked into the project (f.e. with npm link, or the yarn/pnpm/etc linking tools) contains the same dependency as the project does.

In this case, the dependency is not de-duped, and exists in two places: in the project’s node_modules, and in node_module/linked-dependency/node_modules.

For some reason, VS Code (TypeScript?) is preferring the nested dependency, even if they have the same version number, and (for some reason) introducing this weird error.

One way that I get around the problem is, instead of linking a project (which is a difficult thing not to do if you are relying on workspace tools like yarn/npm), to put that dependency’s ref/hash in the dependent’s package.json, so that npm install will install the dependency from VCS (f.e. from a branch that has the work-in-progress changes). In this case, there’s no error, as NPM will successfully de-dupe the duplicate dependencies.

I haven’t observed if this issue happens with duplicate dependencies in non-linked projects (f.e. which could happen if the duplicate dependencies have incompatible versions and can not be de-duped).

As a general way to reproduce, make sure your project has this structure in node_modules:

your-project
  node_modules
    @types
      some-package v1.2.3
  the-linked-dependency (SYMLINK)
    node_modules
      @types
        some-package v1.2.3

And that might generate the error.

one workaround

We can install the dependency from VCS’s like git (note, if the dependency has build steps, this won’t work unless that dependency stores build output in the code repository, or has a prepare script that tells NPM how to build the project):

in package.json:

{
  "dependencies": {
    "the-linked-dependency": "github-username/the-linked-dependency#REF"
  }
}

where REF is a branch name, a commit hash, or a tag, etc.

Once that is in package.json, avoid linking the-linked-dependency so it will no longer be symlinked, and run npm install for it to be installed from VCS (f.e. from GitHub in this case).

I had the same issue and i solved it by changing the name of some declaration file d.ts to the actual name of the component I am trying to add types too so in my case it was: before: @types/styled.d.ts after @types/styled-components.d.ts where styled-components is the full npm package name and the error is gone

Oh and probably importantly considering this seems to be exposed via symlinks, I am on Windows 10

"preserveSymlinks": true doesn’t resolve all errors that I have. I also use pnpm and typescript together. Previously I used yarn and typescript and everything was fine. Now, I have The inferred type of 'configSchema' cannot be named without a reference to '@pnpm-test/core-config/node_modules/yup/lib/string'. This is likely not portable. A type annotation is necessary. and have no idea how to resolve that.

I also set declaration: false for testing purposes but had no luck having it working.

Try with:

{
  "compilerOptions": {
    "preserveSymlinks": true
  }
}

Credits to @imcuttle #42873 (comment)

It does work for link errors using pnpm. thank you very much.

@givebk-bot !donate @antoniopresto $ 5

thanks for your solution! old but gold. ❤️

I also have a problem like this inside a monorepo, and just reinstalling the deps with yarn solves it. It’s happened a few times. Don’t know it could be something to do with the yarn.lock file getting out of sync after merging branches or something. The regenerated lock filed always shows a diff around the package referenced in the TS error.

Don’t really understand what’s going on but hope that helps someone.

Got similar error in Lerna mono-repo with yarn workspace

Work-around was to disable aws-appsync package hoisting in my package.json

{
  "workspaces": {
    "nohoist": [
      "**/aws-appsync"
    ]
  }
}

Same bug TS 3.7.2. The APP uses some REACT stuff imported indirectly (APP has no direct REACT dependency) via intermediary LIB.

TypeScript complains some REACT interface passed indirectly through LIB cannot be named without a reference to LIB/node_modules/REACT.

Temporary solution: set declaration: false in tsconfig.json in APP.

P.S. Dependency structure

APP
  has dependency to LIB (npm link)
  does not has REACT dependency and does not uses REACT stuff directly, but
  imports some react stuff from LIB.

LIB in TS compiled to JS and D.TS
  has dependency to REACT (normal node_modules way)
  exposes some React stuff

I ran into the same issue after linking packages in a yarn workspace

in my case, I was referencing React and it was being picked up as a global type rather than as an import i.e. import * as React from 'react'

changing the name so it doesn’t refer to a global alias fixed my issue e.g. import * as R from 'react'

edit: error came back again, so not sure if the above was the actual fix 😓

@RyanCavanaugh we are bumping into this issue in an Aurelia app we are building.

It has appeared after upgrade from TS 3.1.x (now on 3.4.5).

For us the problem is exposed with declaration:true when we yarn link different packages together for dev.

I’ve been trying to put together a repro for you and have got something although it’s not perfect (problem is only visible via VS Code and I havent been able to determine the difference in the CLI build).

If you clone https://github.com/simonfox/repro-plugin-one and https://github.com/simonfox/repro-plugin-two and run yarn for both. And then in plugin-one run yarn link plugin-two. Then you will see the issue in src/features/feature-one/actions.ts (you may need to reload the VS Code window after linking).