Skip to content

Support custom/non-vendor modules for libΒ #45959

Closed
@delucis

Description

@delucis

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 of include, which can complicate some set-ups and is not ideal in tsconfig 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions