Repository navigation
Package dependencies and The inferred type of ... cannot be named without a reference to ... #29808
Description
Activity
It'd be great to have a concrete way to repro the OOM exception
Ryan Cavanaugh (@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:truewhen weyarn linkdifferent 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-oneandhttps://github.com/simonfox/repro-plugin-twoand run yarn for both. And then in plugin-one runyarn link plugin-two. Then you will see the issue insrc/features/feature-one/actions.ts(you may need to reload the VS Code window after linking).
Reacted by Huan LiOh and probably importantly considering this seems to be exposed via symlinks, I am on Windows 10
Reacted by Igor, Wenzhao Hu, Kousha Talebian, Eric Ferreira, André König, Narek Musakhanyan and 杰枫Same here on Windows 10 x64 Pro.
I have created directory junction withD:\>mklink /j p D:\projects.
It works inD:\projects, but does fail inD:\p.Simon Fox (@simonfox) you found any workaround?
@nthypes no sorry
Getting same error here 😩 after upgrading to
3.6.3from2.9.1Sorry, 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
solved with Module resolution:
{ "compilerOptions": { "baseUrl": ".", // This must be specified if "paths" is. "paths": { "graphql-compose": ["node_modules/graphql-compose/"] }, // ... }
Reacted by Dylan Seago, Andrew Noblet, Daniele Orlando, Alec Larson, Liang, Vlad Zainchkovskyi, Anuraag, Victor Villas, Andrii Pavlenko, Quentin Woivré and 36 moreReacted by Artem Zakharchenko, Tài Hà, Sahas Prajapati, Sergei Meza, Aleksei Gmitron and Christian IvicevicReacted by Artem Zakharchenko, Tài Hà, Antonio Moura, Ingo Wonner, Sans X, Sergei Meza and Aleksei Gmitron- added a commit that references this issue
on Nov 6, 2019 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
Reacted by Fathy Boundjadj, Sergey Seleznev, 崮生, Philipp Heinze, Igor, Jan Karres, ski, odex21, Verekia, Luis Marsiglia and 2 moreSame 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: falseintsconfig.jsonin 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 stuffReacted by paperllc and SunDLWell, 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_typescriptIt 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.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 regardsReacted by Pedro Simeão Carvalho, Justin Hopper, Chadwick Maycumber, Stefan Åstrand, Thyago Weber, jinyangwang, Shihui Long and Igor9 remaining items
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 existedI'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.
Got also a similiar error at a
lernamonorepo, using onlynpm(no yarn workspaces).The actual issue was that i've had
@types/reactinstalled only in one package, but used the typings in multiple packages, thus withlerna hoistit only was existing in/packages/node_modules/packageBand not in/node_modules.After adding it to the other depending packages, e.g. in
devDependenciesand 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" } }I also have a problem like this inside a monorepo, and just reinstalling the deps with
yarnsolves it. It's happened a few times. Don't know it could be something to do with theyarn.lockfile 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.
Reacted by Kamil Mielnik, Marie Gauthier, Khari (Kuh-ree) Johnson and Rabin JulienI 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.jsonI restarted the damn IDE and it disappeared :/
Try with:
{ "compilerOptions": { "preserveSymlinks": true } }Credits to Cong Yu (@imcuttle)
#42873 (comment)Reacted by Paul Damnhorn, Auu, u3u, newboy, Matt Wojick and hunter2009Reacted by Towry WangReacted by Paul Damnhorn and Ingo WonnerReacted by Paul Damnhorn"preserveSymlinks": truedoesn't resolve all errors that I have. I also usepnpmandtypescripttogether. Previously I usedyarnandtypescriptand everything was fine.
Now, I haveThe 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: falsefor testing purposes but had no luck having it working.Reacted by Eric Bartels, Arthur Gailes, Aleksei Tsikov, mino and Towry WangHey! Looks like someone invited me to this issue.
givebk bot (@givebk-bot) !donate Antonio Silva (@antoniopresto) $ 5
thanks for your solution! old but gold. ❤️
Reacted by Towry WangReacted by Antonio Silva, Victor Duarte and Towry Wang- 🎁 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
Try with:
{ "compilerOptions": { "preserveSymlinks": true } }Credits to Cong Yu (@imcuttle) #42873 (comment)
It does work for link errors using pnpm. thank you very much.
Reacted by Andrew Freeman, Wésley Guimarães and Jarrod PayneReacted by Towry WangThe
"preserveSymlinks": truefix this but break others.
When it is turned on, TypeScript cannot resolve transient types.e.g.
@types/react-router-domusesreact-router. But TS cannot resolve it asreact-routeris not add as a direct dependency, so it resides in<rootDir>/node_modules/.pnpm/....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!
- locked as resolved and limited conversation to collaborators
on Nov 19, 2022
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,
Before updating,
1.0.0of package "A" (older version)2.51.1of package "B" (older version)1.0.0of package "A" has2.51.1of package "B" (older version)After updating package "A",
1.0.1of package "A" (newer patch version, bug-fix, no.d.tschanges)2.51.1of package "B" (older version)1.0.1of package "A" has2.51.2of package "B" (newer patch version, bug-fix, no.d.tschanges)There's a package version mismatch here.
My project has
2.51.1of "B" but the package I updated has2.51.2of "B".In the newer version of "A" and "B", no
.d.tsfiles 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.
tsccrashed; out-of-memory exception.VS Code gave me the error,
Workaround
The workaround is to just update "B" to
2.51.2in 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.tsfiles are added/removed/modified.Related Issues: #29221