Move TextEncoder out of lib.dom.d.ts.
See original GitHub issueSearch Terms
TextEncoder
Suggestion
Put (window|global).TextEncoder
in a library that is automatically available to both browser and nodejs.
Use Cases
TextEncoder
now exists on window
in all major browsers as well as on global
in NodeJS (as of NodeJS 11). At the moment, the TextEncoder
definition lives in lib.dom.d.ts
which means it isn’t available when working on a project/library that is targeting both NodeJS and Browser.
I don’t mind submitting a PR, but I don’t know where the appropriate location for such a change is, and how to reconcile it properly with removal from lib.dom.d.ts
. It isn’t part of an annual ES specification, but it should go somewhere that is automatically included in both browser and node now that it is implemented by both. The specification for it can be found at https://encoding.spec.whatwg.org/ and I believe that is what has been implemented in NodeJS.
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.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:10
- Comments:9 (6 by maintainers)
Yes, for console, TextEncoder, and URL (and their associated types). Making users include dom typings is inaccurate if they only want those types.
While TextEncoder was moved in NodeJS 11 to match the web versions API, console has matched for a long time (not just NodeJS 11+). In a perfect world, all versions of node types would get
console
global from some shared location, while only node 11+ types would get TextEncoder from a shared location. I recognize this may complicate things even more though.