TypeScript
TypeScript copied to clipboard
microsoft
Add option to include default typeRoots when overriding typeRoots
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:
- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- [x] This feature would agree with the rest of TypeScript's Design Goals.
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.
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.
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/**", ...]
}
}
@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" ?
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.
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?
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
+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
Bump.
@RyanCavanaugh - How can any of us be helpful here in moving this forward?
nth-ing that this is a big problem when using yarn pnp in a monorepo.
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.
