需要澄清目标和lib编译器选项

Question

我发现我对目标和lib选项以及它们如何与源代码中支持的功能进行交互感到困惑.我觉得文档需要改进一点,所以在提出问题之前在这里问.

我天真地假设target指定输出代码运行所需的JS版本(添加了模块加载器).因此,我们总是可以使用TS支持的所有高级JS功能(如对象传播),编译器为我们指定的目标生成合适的代码.我假设它有polyfills等,代码只会在目标VM上运行.

但是,lib选项的文档指定了取决于目标的默认库.但是,libs会影响可用的源类型,从而影响我们可以使用的代码.因此,我们可以使用的源功能取决于目标.这不像我预期的那样.我应该说我对lib的理解是它们是使用不同API的类型,尽管文档并没有真正说明它们是什么.

我可以看到,这里有一些语言功能不依赖于类型和其他类型.然而,目前尚不清楚这是否是造成这种情况的部分原因.

有人可以澄清一下吗？

第二个问题是,为什么ES6和ES2015 lib通常被记录为同一个东西.

谢谢

Answer 1

(这开始是一个评论,但它太长了.)

这有点令人困惑,部分原因是它背后有一些历史.我没有资格权威地回答这个问题,但是我从早期开发就开始关注TypeScript,这是我的理解:

--target告诉编译器在编译时要包含哪些库版本(例如,ES5如果使用会产生编译器错误Promise,但ES6会知道所有内容Promise)以及编译器发出的JS版本(例如ES5将下编译类语法,但是ES6会留下来).
--lib之后添加,以便您在编译时更好地控制要使用的库版本,而无需更改发出的JS目标.例如,一个常见的问题是您可能包含用于ES6库功能的polyfill,例如Promise,但您希望通过向下编译class语法来定位ES5浏览器.在--lib你到处之前你要么必须目标ES6以避免编译错误Promise,然后再使用Babel 进行下编译,或者你可以定位ES5并提供自己的类型定义,Promise以便编译器不会给你一个错误.现在--lib你可以简单地说你的--target ES5和--lib ES6,并且编译器不会抱怨Promise但仍然向下编译到ES5.
这两个选项都不会导致TS发出任何库polyfill(Promise等),正如你明显发现的那样; 您有责任提供正确的运行时库.它只发出一些低级语言兼容性助手,比如__extends和__awaiter(不同之处在于,class或者async不仅仅是可以在运行时进行polyfilled的API,它是一种具有语法含义的语言特性).该--lib选项只是根据您在运行时知道的内容获得正确级别的编译检查的方法.
至于为什么有两个ES6和ES2015,这只是因为ECMAScript中更改了名字,并留下TS旧名称作为向后兼容的有效选项.:)

您会发现这些TS问题涵盖了很多内容:

谢谢你的回答.所以我看到混乱的根源是```-target```执行这两件事情,加上一些语言功能被下编译,而其他语言功能则没有,但需要在源代码中使用lib. (2认同)
这也回答了另一个问题 - 为什么你会使用TS和Babel :)所以一个很好的方法来定位许多当前的浏览器是TS中的目标ES6与Babel转换为ES5. (2认同)
“这有点令人困惑，部分原因是它背后有一些历史”总的来说，现代 JS 。 (2认同)