Resolving hoisted `typeRoots` paths
See original GitHub issueTypeScript Version: 3.6.2
Search Terms:
- resolve typeRoots in parent package node_modules
- sharing tsconfig in yarn workspaces
- use hoisted tsconfig in child package
Code
I’ve set up a Lerna monorepo which uses Yarn Workspaces. Within this monorepo is a config package, which other packages depend on. This config package has @types/node
and @types/jest
as dependencies.
From sibling packages, the shared config is used like so:
{
"extends": "@project/config/ts.json",
"include": ["src", "tests"],
"compilerOptions": {
"outDir": "lib"
}
}
In the shared config, I point to the appropriate types root:
{
"compilerOptions": {
// ...
"typeRoots": ["node_modules/@types"]
}
}
However, within the shared config package, @types/*
have been hoisted from the local node_modules
to the monorepo’s top-level node_modules
. This behavior is usually fine given node’s resolution… but it seems the config does not resolve to its parent’s node_modules
.
Expected behavior:
For the specified type root to resolve to the parent’s node_modules
Actual behavior:
Tests fail with messages such as Cannot find name 'describe'. Do you need to install type definitions for a test runner? ...
One workaround:
{
"compilerOptions": {
// ...
"typeRoots": ["../../node_modules/@types"]
}
}
This workaround isn’t very clean. Lerna & Yarn definitely pose some complexity for type root resolution. Hopefully resolving parents is considered a worthwhile modification.
Please let me know. Thank you 😃
Issue Analytics
- State:
- Created 4 years ago
- Reactions:32
- Comments:9
This is one that we had been resolving with a workaround similar to the one that @harrysolovay proposes. Unfortunately, we quickly ran into an issue there with different versions of a
@types
package. Our particular situation was theinternal-package-a
had a dependency on@types/node@12.0.0
where another had one on@types/node@13.1.17
. This led to a case where ininternal-package-a
bothnode_modules
and../../node_modules
(at the monorepo root) had a copy of@types/node
, and was causing build failures.We’ve managed to resolve this for the short term by homologating our versions of this type package, but I can see the day coming where we won’t be able to do that and it’ll lead to a crufty, byzantine set of tsconfig rules that expect certain packages in the package root versus the monorepo root (which is exactly the sort of thing we’re looking to avoid).
Very much looking forward to some positive movement on this issue.
I had the same issue. Solved by omitting
typeRoots
entirely, which exposes./node_modules/@types
,../node_modules/@types
, etc. by default.https://www.typescriptlang.org/tsconfig#typeRoots![image](https://user-images.githubusercontent.com/8672064/141829319-4dd008cb-9637-4ccf-a5df-a2a7b59dbb46.png)