Add option to include default typeRoots when overriding typeRoots

[ide]

Search Terms

default typeRoots

Suggestion

By default, when typeRoots is unspecified, TypeScript looks for node_modules/@types in the project's directory and all ancestor directories, similar to Node's module resolution algorithm. This is covered in the tsconfig.json docs and is implemented here.

When specifying typeRoots in tsconfig.json, this overrides the default typeRoots entirely. You can include "node_modules/@types" in your typeRoots array, but that does not include ancestor directories.

This is a feature request to provide a way, such as a new option, to include the default type roots in addition to the overridden values.

Use Cases

The primary use case is within a repository using Yarn workspaces. Yarn hoists npm packages to the workspace root. This means you can end up with a directory hierarchy like this:

.
├── node_modules
│   └── @types
│       └── dependency
└── packages
    └── example
        ├── example.ts
        ├── package.json
        └── tsconfig.json

If tsconfig.json wants to include node_modules/@types in the workspace root (in addition to other type declaration directories specified in typeRoots), it needs to look like this:

{
  "compilerOptions": {
    "typeRoots": ["../../node_modules/@types", ...]
  }
}

Examples

This feature request is a quality-of-life improvement to instead allow for:

{
  "compilerOptions": {
    "typeRoots": [...],
    "includeDefaultTypeRoots": true
  }
}

The default value of this option would be false and would not be a breaking change.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[Taytay]

We need this exact same thing for the exact same reasons. I was looking for a way to say, "In addition to the normal @types folders resolution that Typescript does, please also add the following folders." There is no way to do this that I am aware of.

[nashspence]

This would be useful for me too. Specifically, if in addition to the default @types org I could specify an additional org to check.

I would like to include some custom global utility types in each of my typescript projects that extends a particular tsconfig. These global utility types would be available as an npm package at a path “@myorg/global-types”. I would include this package as a dev dependency. I would then configure the tsconfig typeroots to look first in “@myorg” then fallback to “@types”. I would then add “global-types” to the types array in the tsconfig and all would be well.

I’m also open to being told if I’m missing something. Right now, I use my yarn magic to fake like my types are in @types even tho they are not. This works, but would break in the event that I used one of my packages (which are all git submodules) without the mono-repo package surrounding it - which will eventually be a problem.

[dummdidumm]

Another way to support this could be to add some kind of glob support to typeRoots, so you could write this:

{
  "compilerOptions": {
    "typeRoots": ["./node_modules/@types/**", ...]
  }
}

[eytienne]

@dummdidumm it seems a bit over complicated... I have never seen that type of glob. But this PR could be quite easy, in the code, they are looking after each ancestor node_modules like the node behavior, just adding a condition here and modifying the config schema. "includeDefaultTypeRoots" is a bit long (but "allowSyntheticDefaultImports" too) so maybe "extendsTypeRoots" ?

[yinzara]

This is now a much more serious issue with the introduction of Pnp. Without this feature, there is no way to include additional typeRoots on top of the pnp roots without overriding them completely.

[jonrimmer]

I have a fix for this on my fork, but I cannot PR it due to this issue not being on the backlog: https://github.com/jonrimmer/TypeScript/tree/include-default-type-roots-option

@RyanCavanaugh What feedback are you waiting for on this issue?

[Borduhh]

Running into the same issue when we want to use a private NPM Types module in a Serverless mono-repo

https://stackoverflow.com/questions/66495073/automatically-import-typescript-namespace-from-namespace-type-only-npm-module-in

[psalv]

+1, I'm shipping a typescript source repository and it would be easier if I could specify the types it defines internally rather than needing to build + load the types separately

[lobsterkatie]

Bump.

@RyanCavanaugh - How can any of us be helpful here in moving this forward?

[tzachbon]

This would be a very helpful feature.

[anurag-roy]

+1, This would really be useful.

[anurag-roy]

@RyanCavanaugh Any updates on this?

[fiveable-jferg]

nth-ing that this is a big problem when using yarn pnp in a monorepo.

[Maximaximum]

Any news on this?

[stefancplace]

I would highly appreciate this feature too ...

[gwro]

same 👍

[shrinktofit]

same 👍

[holycanvas]

+1, awaiting this good feature

[nacho4d]

same 👍

[kutsan]

Can you please stop typing no value comments like "+1"? It certainly doesn't help the development process of this issue and you're sending useless notifications, emails to people who subscribed to this thread and waiting actual feedback.

Use 👍🏻 reaction instead.

[nVitius]

@RyanCavanaugh pinging you as you originally added the labels for this issue.

Could you consider re-evaluating this and maybe adding it to the backlog?
This feature would be nice to have for monorepo setups.

My case is for using pnpm workspaces where I have <root>/node_modules but also <root>/packages/<package>/node_modules. I would like to define my default typeRoots in my root tsconfig and have my packages add their node_modules/@types to their own tsconfig (which extends the base one).

[s0ber]

For people who have this issue in Monorepo context, you can "put" your package in a @types organisation with something like this:

{
  "name": "@types/my-monorepo-global-types"
}

and it'll be picked up by typescript automatically without having to override the typeRoots option.

[PaulRBerg]

That's a fantastic idea @s0ber to avoid having to define typeRoots!

Pro tip: if you intend on applying these types globally in your monorepo, do not build the @types/my-monorepo-global-types package. Let the declaration files (*.d.ts) load from src itself - otherwise, you will bump into this problem: Cannot find type definition file for ... The file is in the program because: Entry point for implicit type library.

This is what I have in package.json:

{
  "name": "@types/my-monorepo-global-types",
  "main": "./src/index.d.ts",
  "types": "./src/index.d.ts"
}

And these are the contents of my src directory:

./src
├── assets.d.ts
├── index.d.ts
└── jazzicon.d.ts

[unikitty37]

I am trying to add custom Playwright matchers to a SvelteKit repo. The docs say to add global.d.ts using either typeRoots or include.

Using typeRoots will break resolution of every other type because of this issue. Because SvelteKit generates its own tsconfig in .svelte-kit/tsconfig.json and uses "extends": "./.svelte-kit/tsconfig.json" to include it, I can't use include without copying the include section from that file into the main tsconfig.json.

This means I somehow have to be aware when SvelteKit has changed what it generates so I can re-copy it. Brittle.

Why on earth, if tsconfig.json allows extends, does it not merge things rather than just clobbering them?

The solution from @s0ber is great for monorepo users, but not much use for anyone else. Please could we have a works-for-everyone fix for this?

(Update: I have just noticed that I can include global.d.ts using files, which SvelteKit doesn't set, so that's the simple solution! Not sure why the Playwright docs don't mention this option :)