types in transitive dependencies causing errors. The inferred type of ... cannot be named without a reference to
See original GitHub issueTypeScript 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
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:7 (2 by maintainers)
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.
@RIP21 any update?