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

[AnyhowStep]

TypeScript Version: 3.3.0-dev.20190119

Search Terms: inferred type, cannot be named, reference, package, dependency

This isn't really a traditional bug report. Mostly a PSA of some sort.

Code

The dependencies of interest are,

• My project has a direct dependency to "A"
• My project has a direct dependency to "B"
• "A" has a direct dependency to "B"

Before updating,

• My project has 1.0.0 of package "A" (older version)
• My project has 2.51.1 of package "B" (older version)
• 1.0.0 of package "A" has 2.51.1 of package "B" (older version)

After updating package "A",

• My project has 1.0.1 of package "A" (newer patch version, bug-fix, no .d.ts changes)
• My project has 2.51.1 of package "B" (older version)
• 1.0.1 of package "A" has 2.51.2 of package "B" (newer patch version, bug-fix, no .d.ts changes)

There's a package version mismatch here.
My project has 2.51.1 of "B" but the package I updated has 2.51.2 of "B".

---

In the newer version of "A" and "B", no .d.ts files were added/removed/modified.

---

Expected

Before updating, the project compiled.
So, the rationale is that after updating a patch version, the project should still compile.

Actual

After updating, the project stopped compiling.

tsc crashed; out-of-memory exception.

VS Code gave me the error,

The inferred type of ... cannot be named without a reference to node_modules/A/node_modules/B

---

Workaround

The workaround is to just update "B" to 2.51.2 in my project. After doing so, everything compiles again.

It seems like package versions matter to TypeScript when it comes to transitive dependencies. Even if it's a patch version and no .d.ts files are added/removed/modified.

Related Issues: #29221

[RyanCavanaugh]

It'd be great to have a concrete way to repro the OOM exception

[simonfox]

@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).

[simonfox]

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

[igorpupkinable]

Same here on Windows 10 x64 Pro.
I have created directory junction with D:\>mklink /j p D:\projects.
It works in D:\projects, but does fail in D:\p.

[antl3x]

@simonfox you found any workaround?

[simonfox]

@nthypes no sorry

[whimzyLive]

Getting same error here 😩 after upgrading to 3.6.3 from 2.9.1

[AnyhowStep]

Sorry, guys, I never did create a minimal repro for this.

But if you are getting assignability errors, it may have to do with classes with private properties, or unique symbols, which are nominally typed, and may not be assignable across different package versions.

Even if they're structurally typed, if the interface or type alias is different between the two versions, they won't be assignable to each other (which makes sense, in this case)

I still need to go ahead and make a repro for the assignability thing but I'm on holiday at the moment =x

Not sure if I can repro the OOM anymore, though

[antoniopresto]

solved with Module resolution:

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

[akash-rajput]

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

[al6x]

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

[jeffrson]

Well, this is similar, though not related to package versions. Instead it seems to happen when actually referenced packages are located outside of the project folder.

Here's a repro for Typescript 3.7.5 / 3.8.0-dev.20200204
https://github.com/jeffrson/pnmp_vs_yarn_typescript

It works for npm and yarn, but fails with pnpm and yarnv2. Disable creation of declarations "fixes" it somewhat, as well as appending the type:
export const test: Router
in index.ts.

[josenogueira-7egend]

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

[alidcast]

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 😓

[hemedani]

I have the same issue on a pnpm workspace,
I have 2 type of React Apollo hooks exported :

first exported hook function whit react tsx format like below which is so fine without any errors :

import { useQuery } from "@apollo/react-hooks";
import {
  getCategoryUnits,
  getCategoryUnitsVariables,
  getCategoryUnits_getCategory,
  GQL_GET_CATEGORY_UNITS
} from "@satek/resolvers";
import ApolloClient from "apollo-client";
import React from "react";

interface ParsingProps {
  data: getCategoryUnits_getCategory;
}

interface ErrorProps {
  errMsg: string;
}

interface Components {
  error: React.FC<ErrorProps>;
  loading: React.FC<{ type: "DotsHide" | "DotsShake" | "Circle" }>;
  parsing: React.FC<ParsingProps>;
}

export function useCategoryCategoriesQuery<
  C extends Components,
  V extends getCategoryUnitsVariables
>(components: C, variables: V, client: ApolloClient<object>) {
  let Response: React.ReactElement | null = null;
  const Error = components.error;
  const Loading = components.loading;
  const Parsing = components.parsing;

  const { loading, error, data } = useQuery<
    getCategoryUnits,
    getCategoryUnitsVariables
  >(GQL_GET_CATEGORY_UNITS, {
    variables,
    client
  });
  if (loading) {
    Response = <Loading type="DotsHide" />;
  } else if (error) {
    Response = <Error errMsg={error.message} />;
  } else if (data) {
    Response = <Parsing data={data.getCategory} />;
  }
  return { Response };
}

and other hook function like below which just export data and throw this error The inferred type of 'useCreateCategoryMutate' cannot be named without a reference to '.pnpm/registry.npmjs.org/@apollo/react-hooks/3.1.3_0db28cdd7967d177805e183f143598ec/node_modules/@apollo/react-common'. This is likely not portable. A type annotation is necessary.ts(2742)

import { useMutation } from "@apollo/react-hooks";
import {
  createCategory,
  createCategoryVariables,
  getCategoriesVariables,
  GQL_CREATE_CATEGORY,
  GQL_GET_CATEGORIES
} from "@satek/resolvers";
import ApolloClient from "apollo-client";

export function useCreateCategoryMutate<V extends getCategoriesVariables>(
  variables: V,
  client: ApolloClient<object>
) {
  const [createCategoryMutate, result] = useMutation<
    createCategory,
    createCategoryVariables
  >(GQL_CREATE_CATEGORY, {
    client,
    update: (store, { data: createCategoryMutate }) => {
      if (createCategoryMutate!.createCategory.organization!.id) {
        variables.organizationId = createCategoryMutate!.createCategory.organization!.id;
      }
      const { getCategories }: any = store.readQuery({
        query: GQL_GET_CATEGORIES,
        variables
      });
      store.writeQuery({
        query: GQL_GET_CATEGORIES,
        variables,
        data: {
          getCategories: [
            createCategoryMutate!.createCategory,
            ...getCategories
          ]
        }
      });
    }
  });
  return {
    createCategoryMutate,
    result
  };
}

this error will be gone when I set "declaration": false in tsconfig but I need declaration for build workspace packages

last but not least, when I build the project typescript throw error for several files but create js file for all of them with declaration files.

[Adidi]

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

[flyskywhy]

I solved it by move project position to a clean folder which has no parent node_modules/. For example, if

npm install @textile/js-http-client
cd node_modules/@textile/js-http-client/
npm install
./node_modules/.bin/tsc

will get error:

src/modules/account.ts:53:3 - error TS2742: The inferred type of 'sync' cannot be named without a reference to '@textile/js-http-client/node_modules/web-streams-polyfill'. This is likely not portable. A type annotation is necessary.

53   sync(apply?: boolean, wait?: number) {

but if

mv node_modules/@textile/js-http-client/ ../
cd ../js-http-client/
npm install
./node_modules/.bin/tsc

everything is OK.

[cvrajeesh]

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

[trusktr]

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).

[Tjerk-Haaye-Henricus]

Same issue here. With Typescript 4.1.5.

I wonder why ist this still open, since it's created on February 2019 :D

[tcarrio]

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 😞

[karlismelderis]

In our case we used yarn workspaces and there were two packages with same dependency.
difference was that in one case package had dependency with version ^1.2.3 and second had "*"
and that * got added when version less than ^1.2.3 existed

I'm not able to replicate exact steps here but eventually yarn was installing version that's below ^1.2.3 and this error helped to catch the issue.

[elbakerino]

Got also a similiar error at a lerna monorepo, using only npm (no yarn workspaces).

The actual issue was that i've had @types/react installed only in one package, but used the typings in multiple packages, thus with lerna hoist it only was existing in /packages/node_modules/packageB and not in /node_modules.

After adding it to the other depending packages, e.g. in devDependencies and as optional peer-dependency, the error was solved.

Example of the additions in e.g. packageA:

{
    "devDependencies": {
        "@types/react": "^16.8.6 || ^17.0.0"
    },
    "dependencies": {
    },
    "peerDependencies": {
        "@types/react": "^16.8.6 || ^17.0.0"
    },
    "peerDependenciesMeta": {
        "@types/react": {
            "optional": true
        }
    },
    "publishConfig": {
        "access": "public"
    }
}

[vonkanehoffen]

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.

[roblatprogen]

I got a similar error in a yarn workspace package project that: ... cannot be named without a reference to 'react-bootstrap/node_modules/@types/react'.

Solved by moving "@types/react": "*" from peerDependencies section to devDependencies in package.json

[MoSwilam]

I restarted the damn IDE and it disappeared :/

[daniele-orlando]

Try with:

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

Credits to @imcuttle
#42873 (comment)

[vtereshyn]

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

[givebk-bot]

Hey! Looks like someone invited me to this issue.

[antl3x]

@givebk-bot !donate @antoniopresto $ 5

thanks for your solution! old but gold. ❤️

[givebk-bot]

🎁 Hey @antoniopresto, you have just received U$ 5 from @nthypes! @nthypes thanks for your support! ❤️ @antoniopresto, you can check your balance at https://givebk.io. ═══ (powered by https://givebk.io) ID: 3e747d04-7499-4ff8-a74b-0c162cf4b997

[zhaohuanyuu]

Try with:

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

Credits to @imcuttle #42873 (comment)

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

[unional]

The "preserveSymlinks": true fix this but break others.
When it is turned on, TypeScript cannot resolve transient types.

e.g. @types/react-router-dom uses react-router. But TS cannot resolve it as react-router is not add as a direct dependency, so it resides in <rootDir>/node_modules/.pnpm/....

[RyanCavanaugh]

Closing this for clarity since I'd prefer new issues to misconfiguration questions and banal observations of issue age.

To recap, you get this error when the declaration emitter can't synthesize a legal-looking import path for a file it needs create an explicit import for in order to name a type that was indirectly referenced. It's another way of saying "You can't get there from here".

The declaration emitter is not 100% perfect and it may be possible for a human to write a path that actually is legal in these situations.

If you get this error, generally the best thing to do is to write an import in the erroring file to the module that the declaration emitter is trying to reference. If you can't do this because there's no legal way to do it in your program, then, well, there's your problem -- you're asking tsc to do something impossible.

If you can write an import path that works, generally speaking this is considered a TS bug, though in some cases the module paths are so edge-case that we're not willing to generate them by default. You can log a (minimal) bug outlining the file path that should have been generated but wasn't, and we can take a look.

Happy coding!