Typescript: 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.

[nthypes]

@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

  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.

[nogueira7egend]

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

[alidlorenzo]

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:

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