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

[RIP21]

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/[email protected]", "@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

[RyanCavanaugh]

Is there a repo or something we can look at? The description is good but it's going to be very, very difficult to reconstruct something similar to what you have

[RIP21]

Eh. I'll try to do repro tomorrow. Shouldn't be very hard I assume. We have like 100 these "type annotations" in order to resolve these issues and it's super annoying and rather random.

[weswigham]

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 not about versions here, it's about nesting. You said it yourself,
B => A => testing-library-react => testing-library-dom.

In the process of making declarations for B, we end up needing to print a type from testing-library-dom; if as far as we can tell, B has no direct dependency on testing-library-dom, we can't print the type (since there's no good way to write the path, as far as we know). Adding the import * as _ from '@testing-library/dom' import allows us to discover the direct dependency relationship between B and testing-library-dom, so we then can print the name (since now we know we can just refer to it by package name). We don't look at the node_modules folder _or_ package.json to discover dependencies - only what files actually get loaded by traversing imports; so if at no other point they ever loaded through the directly dependent location symlink, we never even find out that the symlink even exists.

[RIP21]

@weswigham I think I understand what you mean.
I think I also found one tricky case when this simple import doesn't work. It's when it's related to react.

As far as I recall now (I'm from phone and 2AM) I have styled.ts file, in which I have some styled-components.
It's, indeed wraps some React components, so per your explanation, it should now go up to styled-components to find styled-components/mode_modules/@types/react and ask me to provide with type annotation and it does. But when I just add default import of React (without usage) or import * as React without usage too, from 'react' (because you can't import typings) it doesn't work and still complains.
The only solution is to import. This whole deep nested path to react typings inside styled-components. For all others this weird import works, but not in case of React.
Can you check that?

[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?

[RIP21]

@Bessonov never had time for repro because this one is just design flaw or whatever, you name it.
Means. almost makes no sense to make it.
This issue should be closed, although another should be opened that will ask for detailed explanation of the problem and how to solve it in the docs.

And if you're asking me about whether it will be fixed, it won't I think, and I'm creator of the issue not a member of TS team :)