Move TextEncoder out of lib.dom.d.ts.

Search 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.

[sandersn]

Yes, for console, TextEncoder, and URL (and their associated types). Making users include dom typings is inaccurate if they only want those types.

[MicahZoltu]

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.