Resolving hoisted `typeRoots` paths

TypeScript 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 😃

[nagey]

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 the internal-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 in internal-package-a both node_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.

[DeanMauro]

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