Description
Suggestion
π Search Terms
lib
custom
environment
β 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
- 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
If I understand correctly, currently the lib
option in tsconfig
can refer to a list of built-in lib declarations to configure the expected JavaScript environment. #44795 and #45685 (implemented via #45771) seem to partially allow customisation of this by pointing to a node module to override a given lib file, e.g.
tsconfig.json
"lib": "es2015"
package.json
"@typescript/es2015": "npm:some-custom-es2015-lib"
In some environments it would be helpful to be able to provide a non-standard lib file to extend what is available globally.
Would it be possible to support passing these directly to lib
and have them resolved via the usual package dependency route? In this case, custom-lib-module
would be a node module of the appropriate format.
"lib": ["es2015", "custom-lib-module"]
The additional hurdle beyond the module resolution, which #45771 added, is that this would allow values in lib
other than those in the list of values supported currently.
π Motivating Example
This change makes supporting custom JavaScript environments easier, by allowing easy sharing and extending of lib
configurations.
π» Use Cases
I write JavaScript for use inside Cycling 74βs Max. This runs scripts in an environment with a significant number of custom global APIs (I guess comparable to how a browser environment extends the base ECMA standard). For lesser used environments like this, it would be unreasonable to expect TypeScript to provide built-in lib definitions (or even be aware of them), but being able to write, share, and consume custom lib
modules like this would be really helpful.
Current workarounds include:
-
I guess if Support resolving
@typescript/[lib]
in node modules Β #45771 is released in 4.5, it would be possible to hack around this by squatting on one of the official lib names, adding something like"@typescript/dom": "npm:custom-lib-module"
, but that seems suboptimal. (But β from a position of supreme ignorance β maybe points to a fairly easy path for implementing this?) -
Including the custom lib declaration files in
tsconfig.include
. This has the drawback of forcing use ofinclude
, which can complicate some set-ups and is not ideal intsconfig
files that are intended to be shared across projects. -
Using a triple-slash directive. This requires per-file inclusion, which is much less convenient than a project-level option.