types in transitive dependencies causing errors. The inferred type of ... cannot be named without a reference to

TypeScript Version: 3.7.5. or 3.9.0-dev.20200214 (same result)

Search Terms: symlink, rush, yarn, pnpm, not portable

Code I’m using Rush that is heavy on symlinks. I have sure thing only one version of typings of problematic packages as per my yarn.lock file.

"@types/testing-library__dom@*", "@types/testing-library__dom@^6.0.0":
  version "6.12.1"
  resolved "https://registry.yarnpkg.com/@types/testing-library__dom/-/testing-library__dom-6.12.1.tgz#37af28fae051f9e3feed5684535b1540c97ae28b"
  integrity sha512-cgqnEjxKk31tQt29j4baSWaZPNjQf3bHalj2gcHQTpW5SuHRal76gOpF0vypeEo6o+sS5inOvvNdzLY0B3FB2A==
  dependencies:
    pretty-format "^24.3.0"

Same with TL/R

"@types/testing-library__react@9.1.2", "@types/testing-library__react@^9.1.2":
  version "9.1.2"
  resolved "https://registry.yarnpkg.com/@types/testing-library__react/-/testing-library__react-9.1.2.tgz#e33af9124c60a010fc03a34eff8f8a34a75c4351"
  integrity sha512-CYaMqrswQ+cJACy268jsLAw355DZtPZGt3Jwmmotlcu8O/tkoXBI6AeZ84oZBJsIsesozPKzWzmv/0TIU+1E9Q==
  dependencies:
    "@types/react-dom" "*"
    "@types/testing-library__dom" "*"

tsconfig.json

{
  "compilerOptions": {
    "baseUrl": "src",
    "allowSyntheticDefaultImports": true,
    "declaration": true,
    "declarationDir": "./types",
    "declarationMap": true,
    "downlevelIteration": true,
    "emitDeclarationOnly": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "jsx": "preserve",
    "lib": ["dom", "es2018"],
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "preserveSymlinks": true,
    "strict": true,
    "target": "esnext"
  },
  "include": ["src"],
  "exclude": [
    "./src/**/__tests__/**/*.ts",
    "./src/**/__tests__/**/*.tsx",
    "./src/**/*.test.tsx",
    "./src/**/*.test.ts"
  ]
}

I have a package B, that uses a function from library A that is also in my monorepo, that uses @types/testing-library__react that uses @types/testing-library__dom. So B => A => testing-library-react => testing-library-dom library A emits declarations, no problem. (when I set tsconfig to have preserveSymlinks, before, I had the same kind of error for A) B uses function from A, tries to generate its own declarations, same tsconfig.

Expected behavior: B generates declarations without errors.

Actual behavior: B fails with

error TS2742: The inferred type of 'renderWithStore' cannot be named without a reference to '@package/A/node_modules/@types/testing-library__dom/queries'. This is likely not portable. A type annotation is necessary.

This happens with yarn as well as with pnpm and I never check with npm. I know the behavior of TS that does that when there are multiple versions of typings and the compiler cannot guess which one is right and decides to error out instead. It’s all good, but here I have 100% the same version of typings everywhere physically on the disk and in yarn.lock and it’s probably a bug. It’s just I have one that is symlinked and deep, and one that is laying around in node_modules/@types/testing-library__dom and one that is nested in my symlinked package that makes it node_modules/@package/A/node_modules/@types/testing-library__dom So there are indeed two versions physically (copies), but they are exactly the same as per yarn.lock so it should emit correctly based on their package.json without additional clarification/annotation? Isn’t it?

Adding this to file in B fixes it tho, but it’s a hack and I don’t want to relate on them 😦

import * as _ from '@testing-library/dom'

And working with monorepo this happens to me ALL THE TIME quite randomly 😦

Related Issues: https://github.com/microsoft/TypeScript/issues/30858

[RIP21]

BTW. Adding somewhere in docs a good nicely written explanation with examples of that particular topic will be super awesome and useful in order to explain that behavior using it and to get better understanding of this situation i.e. “whens and whys” for broad audience plus to mitigate yet another duplicates of this and similar issues 😃

I’ll try to make a repro anyway and so you can approve whether it’s intentional behavior or a bug so we can close this one for good.

[Bessonov]

@RIP21 any update?