TypeScript: typeRoots is not finding custom declaration file

TypeRoots is really a support we have added for back compat with typings and to allow migration, so we tried to keep it out of the docs as much as possible to avoid confusion.

@mhegazy Having a supported feature with little-to-no documentation is what drives confusion. Please properly document features like this but be liberal with your warning language. For example:

Note: This feature is provided for backwards compatibility with typings to support migration. See the release notes [here] for more information.

This would be vastly preferable to having to scan GitHub Issues, StackExchange, etc. for information.

"typeRoots" is meant for global code. i.e. something that is declarated in the global namespace, and you want to include it. this is why your declare module 'graphql-list-fields' {.. works, since it just declares a module with that name in the global namespace.

For modules, they have thier own scope, all you need is path mappig…

somethign like:

{
    "compilerOptions": {
        "target": "es5",
        "baseUrl": "./",
        "paths": {
            "*" : ["src/@t`ypes/*"]
        }
    }
}`

One thing I don’t understand here is that:

tsconfig.base.json:

"typeRoots": ["node_modules/@types", "types"],

And a directory structure:

/node_modules/@types/something/index.d.ts
/types/something-else/index.d.ts

It won’t get picked up at all in my nrwl/nx repository. I can try a million things but if I move that something-else folder into node_modules/@types it’ll magically work and get picked up, which suggests the typeRoots does absolutely nothing as node_modules/@types is magically handled.

Marking typeRoots as deprecated and saying it works in a weird/quirky way would have at least stopped me trying to use it.

The only way I’ve managed to add local types each time I’ve needed to, is by spending hours fighting with my tsconfig.base.json and stumbling upon the mhegazy comment above

I kept getting bitten by this and forgetting about having to configure the paths option as well, so I created a simple repository with the proper settings. Hope it helps someone.

I’m being bit by this as well. I couldn’t get custom types for a 3rd party project picked up no matter what I tried. It was working for a while by copying the folder into node_modules/@types, but tsc or another process validates that directory and deletes unexpected files.

{
    "paths": {
          "something": ["types/something"]
    },
    // typeRoots does not need to be set
}

This seems to work but it was extremely unintuitive and under-documented. It didn’t occur to me to try paths until I found this thread after many hours of failures. I thought paths was for “A series of entries which re-map imports to lookup locations relative to the baseUrl” (https://www.typescriptlang.org/tsconfig#paths), and unrelated to resolving type declarations.

Thanks for clearing that up @mhegazy. I think it would be helpful if this was explained more in the TypeScript docs, possibly under the declaration files section.

I still think it would be helpful to have the docs updated as stated in my previous comment @typescript-bot

TypeRoots is really a support we have added for back compat with typings and to allow migration, so we tried to keep it out of the docs as much as possible to avoid confusion.

Not sure if this fits in the declaration file section. we do have a note about it in https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping

I can add a note in the declaration file section about module resolution section as a whole.

give that section a read and let us know if you still find docs in it lacking

This thread says that typeroots is really for backwards compatibility. I am trying to use it to author types for definitively typed. How else would I properly test these types without typeroots? I have generated types using dts-gen and added types to my type roots and still no luck 😦

@gaurav5430’s comment got me on the right track!

My original folder layout:

@types/
  index.d.ts
src/
  index.ts
package.json
tsconfig.json

My tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": "./",
    "declaration": true,
    "esModuleInterop": true,
    "module": "commonjs",
    "outDir": "dist",
    "paths": {
      "*": [
        "@types/*"
      ]
    },
    "skipLibCheck": true,
    "sourceMap": true,
    "strict": true,
    "target": "es5",
    "typeRoots": [
      "node_modules/@types",
      "@types"
    ],
  },
  "include": [
    "src/**/*"
  ]
}

I was still getting errors and I could not understand why. Turns out, @types/index.d.ts should actually be named after the module that doesn’t have types. So, for me I had to change: @types/index.d.ts to @types/csv-to-js-parser.d.ts.

(Contents of that file being declare module "csv-to-js-parser";)

FINALLY

Also, this issue is super annoying.

In my case, the issue was that I’ve been using include and exclude. The issue is that I was trying to access the global types from a file that wasn’t included.

so I just remove the include and kept only the exclude, and now works as expected

Oh I see. Yeah, that is the page that I needed to begin with. I think it would be nice to have at least a brief mention of path mapping and maybe a link to that doc somewhere under https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html.

for anyone finding this issue i was able to resolve this in my code base by adding custom types to the tsconfig.base.json after declaring them in the typeRoots

tsconfig.base.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "rootDir": ".",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "target": "es2015",
    "module": "esnext",
    "lib": ["es2017", "dom"],
    "skipLibCheck": true,
    "skipDefaultLibCheck": true,
    "baseUrl": ".",
    "paths": {
      "@prisma-client": ["packages/libs/prisma-client/src/index.ts"],
      "@ui/meeting": ["packages/libs/ui/meeting/src/index.ts"],
      "@ui/shared": ["packages/libs/ui/shared/src/index.ts"],
      "@ui/util": ["packages/libs/ui/util/src/index.ts"]
    },
    "typeRoots": ["types", "node_modules/@types"],
    "types": ["@emotion-types", "@window-types"]
  },
  "exclude": ["node_modules", "tmp"],
  "files": [],
  "include": []
}

type dir

SO post - second answer

Thx a fucking ton @mhegazy ! 🎉 That path entry for @types was finally the missing piece which made my non-standard project setup work. I spent days on this.

I have a library written in javascript, which exposes type declarations to external consumers. These type declarations are generated automatically using the typescript compiler in a types folder. In the consumer, it works fine, but I would like to use the same declarations within the library as well for intellisense/autocomplete within the IDE

I initially thought that typeRoots would be the way to go, but as discussed above, it seems to be only applicable for global modules / types.

as @mhegazy suggested, I tried using paths to accomplish this. I can’t make it work with relative paths, though it works fine with aliased absolute paths.

The below does not work

// src/packageA
...some code

// src/@types/packageA
...generated type definitions

// usage within the library - does not work
import packageA from '../../packageA'

// tsconfig
paths: {
  "*" : ["@types/*", "*"]
}

but the below code works:

// src/packageA
...some code

// src/@types/packageA
...generated type definitions

// usage within the library - works, but this is not what I want
import packageA from 'packageA'

// tsconfig
paths: {
  "packageA" : ["@types/packageA/*", "*"] //notice the aliasing here
}

This also works:

// src/packageA
...some code

// src/@types/packageA
...generated type definitions

// usage within the library - works, but this is not what I want
import packageA from 'absolute/path/from/base/url/'

// tsconfig
paths: {
  "*" : ["@types/*", "*"]
}

Note that both of the working versions require some change in my webpack module resolution as well to work correctly, but at least typescript seems to be resolving them correctly.

Am i missing something here, or is it generally not possible to make paths work with relative paths ?

If you don’t mind slow down your application starting process little, you can just add TS_NODE_FILES=true to your package.json’s start script and all custom declaration file will be found.

for anyone finding this issue i was able to resolve this in my code base by adding custom types to the tsconfig.base.json after declaring them in the typeRoots

@ALFmachine big ups for the types after typeRoots… can’t believe the order matters 😮