The existence of /// reference directives in dependencies breaks explicit typeRoots ordering

[a-non-a-mouse]

🔎 Search Terms

typeroots triple slash directives ordering

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about reference directives

⏯ Playground Link

No response

💻 Code

We are explicitly including our own types in typeRoots before node_modules/@types:

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

because we're making some custom changes to js/node types. This has been working great until we recently tried to switch to vitest which includes vite which has:

/// <reference types="node" />

in a file, which breaks some of our types as we have conflicting interfaces with @types/node

🙁 Actual behavior

vitest ⇒ vite ⇒ node types is discovered before typeRoots is processed, meaning typeRoots ordering is effectively useless as any dependency can just force type injections before they're processed.

🙂 Expected behavior

typeRoots ordering should apply first, THEN types from dependencies

Additional information about the issue

No response

[RyanCavanaugh]

I'm not quite sure what you mean by typeRoots ordering being different -- do you mean the order that the types directives get processed? Can you post a sample repo we can look at?

[a-non-a-mouse]

I mean that the /// directive from src/file.ts ⇒ node_modules/vitest/somefile.ts ⇒ node_modules/vite/somefile.ts ⇒ node_modules/@types/node appears to be processed before typeRoots.

So the @types/node types are loaded before our types, despite our typeRoots setting telling them to load after.

The result is that our types throw errors about conflicts with @types/node since those are loaded first, and more importantly we can't actually replace certain types in @types/node (specifically any in interfaces that conflict). Simply commenting out import from vitest resolves it.

I'll make a sample repo shortly

[jakebailey]

typeRoots just affects how @types resolution proceeds; which dirs to look for @types in (the "type roots"). https://www.typescriptlang.org/tsconfig/#typeRoots

But this doesn't allow you to place your own files before others; things are still loaded in reverse dependency order.

I think the fix is either to make your types not conflict, patch @types/node in your environment, or convince vite to not load the node types.

[a-non-a-mouse]

We can't patch @types/node, that's my entire point.

If vite is included, anywhere in a project, then @types/node is included before our own types, so it is impossible to patch conflicting interfaces.

I think the fix is either to make your types not conflict

erm... many @types/node types are slightly wrong, or too loose. Devs should be allowed to patch them.

[jakebailey]

If the types are wrong, can you send PRs to DT to fix them, or file discussions there? Or bring them up in the DT channel on the discord?

In any case, typeRoots is not the option for this; it's only intended to help control which places we look for @types packages. There is nothing in TS that can force certain files to come first in the compilation, except for lib.d.ts.

[a-non-a-mouse]

sample repo: https://github.com/a-non-a-mouse/0194011212380128310923810

[a-non-a-mouse]

I'm not trying to have a discussion about the correctness of DT :)

The fact is, even if we were to not install @types/node, and completely clone that repo, and make our own modifications to it, vite would install it, and those types would be loaded globally instead of ours.

This isn't just an issue for node types, it's also an issue of global type injection of whatever anyone wants into any parent repo, but that's a somewhat different discussion.