Support having '@types/web' as overriding 'dom' in TypeScript's lib resolver

Suggestion

I’d like to be able to install @types/web and have the following happen:

• Other dependencies (like from DT) using something like /// <reference lib="dom"> do not resolve to the vendored libdom.d.ts
• The default inclusion of dom in a project via lib would automatically pick up @types/web (or be fully suppressed)

🔍 Search Terms

dom types/web web lib

✅ Viability 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
• x ] This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

⭐ Suggestion

1. Hardcode some sort of dom -> @types/web inside the TS compiler’s
2. Support some kind of pragma in @types/web

1 - Hardcoding

Pros: @types/web is a special case (though there could be more in the future) and this could be the smallest possible change.

Cons: It feels a bit meh.

2 - Pragmas

Pros: We have existing pragmas: /// <reference no-default-lib="true"/> for type of thing. This answer is totally generic and would allow others to have their own implementations of other deployed libs.

Cons: I’d need to check, but this might mean looking for the pragmas across all @types dts files before we can reliably use the files inlib

[orta]

#45771 shipped this into the TypeScript 4.5 - the answer was to leave dependency managers to handle the resolution

This answer to supporting your own versions of in-built libraries uses the node_modules resolution structure to let you define libraries. The path lookup looks like:

• lib.dom.d.ts -> @typescript/dom
• lib.dom.iterable.d.ts -> @typescript/dom/iterable
• lib.es2015.symbol.wellknown.d.ts -> @typescript/es2015/symbol-wellknown

If you made a package which just sets up @typescript/es2015/symbol-wellknown.d.ts without @typescript/es2015/index.d.ts, then es2015 would still resolve to the TypeScript hosted version.

All JS dependency managers support this syntax:

{
  "dependencies": {
    "@typescript/dom": "npm:@types/web"
  }
}

[MartinJohns]

With the pragma approach, what would happen if two packages aim to replace the definitions? This could easily happen with unfortunate dependencies.

A third option may be to have it explicitly configured in the tsconfig.json. I’m the last person who’d ask for yet another flag / option, but it sounds sensible for this. This would allow replacement of any library file, and it’s explicit (no magic).