Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support overriding lib (e.g. lib.dom.d.ts) paths #29237

Closed
5 tasks done
bradleyayers opened this issue Jan 2, 2019 · 2 comments
Closed
5 tasks done

Support overriding lib (e.g. lib.dom.d.ts) paths #29237

bradleyayers opened this issue Jan 2, 2019 · 2 comments
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript

Comments

@bradleyayers
Copy link

bradleyayers commented Jan 2, 2019

Search Terms

  • lib / lib.dom.d.ts
  • override / replace / substitute
  • triple slash reference
  • path

Suggestion

Provide a compiler option that allows the path to a lib file to be overridden. For example being able to provide a local path to lib.dom.d.ts so that when the dom lib is included, the local path is used rather than the version bundled with TypeScript.

Use Cases

I want to write a library that targets multiple environments (specifically node and web) that has type safety to ensure that globals (that only exist in one environment) are not unsafely referenced.

The current approach to copy lib.dom.d.ts that comes with TypeScript and edit it to remove all declare const lines, and then include it via include and be sure not to include dom in compilerOptions.lib. The downside of this approach is that when an upstream type definition (e.g. @types/jsdom) has a triple slash reference to the dom lib, the lib.dom.d.ts bundled with TypeScript is included.

Examples

A new compilerOptions.libPaths option would be available that would allow paths to libs to be overridden, e.g.

{
  "compilerOptions": {
    "libPaths": {
      "dom": "./types/lib.dom-no-globals.d.ts"
    }
  }
}

This wouldn't implicitly include the dom lib, it would still need to be explicitly included via compilerOptions.lib or by a type definition using a triple slash lib reference /// <reference lib="dom" />

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.
@weswigham weswigham added Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Jan 3, 2019
@HermitSun
Copy link

HermitSun commented May 25, 2020

In my usage scenario, this (or similar) feature is also very useful. The problem is I cannot extend global variables that support multiple environments.
For example, I need to write test cases for my code running in the browser. I need to simulate a series of variables in the window in the node environment; but it is actually running in the browser. In order to make it work, lib.dom.d.ts is required; but this will cause a conflict, because I customized the window in Node, and this is in conflict with lib.dom.d.ts.
In use, I can manually write a lib.dom.d.ts, and then no longer introduced in compiler options, as @bradleyayers said; but if I want to write a library, this problem is difficult to solve.
Maybe a feature that can partially override lib's type can be provided?

@saschanaz
Copy link
Contributor

Seems #45771 solves this?

@andrewbranch andrewbranch added Fixed A PR has been merged for this issue Suggestion An idea for TypeScript and removed Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Sep 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants