搜索词
TextEncoder
建议
将 (window|global).TextEncoder 放入一个库中，该库可以自动提供给浏览器和nodejs。
使用场景
TextEncoder 现在存在于 window 的所有主要浏览器以及 NodeJS(截至 NodeJS 11)的 global 上。目前，TextEncoder 的定义位于 lib.dom.d.ts 中，这意味着在针对同时支持NodeJS和浏览器的项目/库时无法使用。
我不介意提交PR,但我不知道这种更改的合适位置在哪里，以及如何与从 lib.dom.d.ts 中移除进行妥善协调。它不是年度ES规范的一部分，但现在既然已经在两者中都实现了，它应该放在一个自动包含在浏览器和node的地方。可以在 https://encoding.spec.whatwg.org/ 找到它的规范，我相信这就是NodeJS中实现的内容。
检查清单
我的建议满足以下准则：
- 这不会对现有的TypeScript/JavaScript代码造成破坏性更改
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不根据表达式的类型发出不同的JS的情况下实现
- 这不是一个运行时特性(例如库功能、JavaScript输出的非ECMAScript语法等)
- 这个特性会与 TypeScript's Design Goals 中的其他部分保持一致。
9条答案
按热度按时间8oomwypt1#
我还在miniSphere中实现了
TextEncoder和TextDecoder,所以👍，这样就不需要强制依赖lib.dom.d.ts来使用编码API。yzuktlbb2#
值得注意的是，
console.log在dom和node定义文件中重复出现，这意味着即使您可以在浏览器和节点中安全地使用console.log,您也必须依赖于dom或@types/node才能实际使用它，这可能导致错误地依赖于您包含的任何库中的某个内容，并且编译器不会正确地警告您。3z6pesqy3#
@rbuckton建议创建一个新的文件lib.dom.textencoder.d.ts来包含TextEncoder类型，然后节点类型可以使用
/// <lib=.../>引用。他指出，URL API也来自WHATWG规范，并存在同样的问题。我们希望一次性进行这个更改，因为每个引入新lib.dom.*.d.ts到
@types/node的Typescript版本都需要在@types/node中进行typesVersion分支，以便旧版本不引用不存在的文件。换句话说，至少节点11和节点12的类型必须分叉以支持在此更改之前和之后的Typescript版本。另一方面，目前的情况很糟糕，因为节点类型作者无法包含TextEncoder或URL,因为这会导致那些确实想要同时拥有node和DOM类型的项目的冲突。因此，各个项目不得不错误地添加DOM类型。
节点类型作者们，你们对为node 11和12创建一个typesVersion分支需要多少工作来更新节点类型有什么看法？你们认为这样做有什么好处？
4zcjmb1e4#
为了澄清，这里的目标是在加载node typings时不再需要dom typings吗？
是否应该对
console做类似的处理？weylhg0b5#
是的，对于控制台、TextEncoder和URL(以及它们的相关类型)。如果用户只想要这些类型，那么让他们包含DOM类型是不准确的。
owfi6suc6#
在Deno的人们也依赖于TextEncoder。
/cc @ry@piscisaureus
sh7euo9m7#
我完全支持将共享组件从节点类型中分离出来，我们已经遇到过很多麻烦。这里有什么关于破坏性更改的担忧？理想情况下，节点类型应该只是添加库引用，我们应该没问题。
qojgxg4l8#
@SimonSchick旧版本的TypeScript不会包含共享组件的新文件，因此我们需要通过
typesVersions目录并行维护两个版本的Node。由于共享组件已经全局化，因此这将适用于所有Node版本，我认为是Node 10+。j5fpnvbx9#
虽然TextEncoder在NodeJS 11中被移到了与Web版本API相匹配的位置，但console已经匹配了很长时间(不仅仅是NodeJS 11+)。在一个完美的世界里，所有版本的node类型都会从某个共享位置获得
console全局变量，而只有NodeJS 11+类型的node会从共享位置获得TextEncoder。尽管如此，我认识到这可能会使事情变得更加复杂。