尽管tsconfig目标设置为ES5，为什么仍需要ES7/阵列polyfill [英] Why is ES7/array polyfill needed despite the tsconfig target is set to ES5
问题描述
我在tsconfig.json中具有以下设置.我添加了"es2017"来使用Array.includes.:
I have the following settings in thetsconfig.json. I added "es2017" to use Array.includes.:
{
"compilerOptions": {
"lib": [
"es6",
"es2017",
"dom"
],
"module": "es6",
"target": "es5"
}
}
现在，我意识到，必须将import 'core-js/es7/array';添加到polyfills.ts，以便将Array.includes也用于Internet Explorer11.tsconfig.json中的target设置为es5，没有Array.includes.
Now, I realized, that I have to add import 'core-js/es7/array'; to the polyfills.ts, to use Array.includes also for the Internet Explorer 11. The target in the tsconfig.json is set to es5, which does not have Array.includes.
为什么需要添加polyfill?
Why do I need to add the polyfill?
推荐答案
TypeScript 不会自动polyfill 代码. 正式"的GitHub相关问题的原因似乎是@RyanCavanaugh 说 :
TypeScript does not auto-polyfill code. The "official" reason from the relevant GitHub issue seems to be, as @RyanCavanaugh said:
让编译器尝试找出所需的[ES20XX]方法，在何处发出它们，以及何时使用针对那些不希望发出polyfill的控件，以及如何使用这些方法更改这些polyfill的来源等等，这是一个很大的麻烦，因为在脚本上下文中仅包含普通的[ES20XX] polyfill库可能带来的收益并不能证明这一点.
Having the compiler try to figure out which [ES20XX] methods you need, and where to emit them, and when, with controls for people who don't want the polyfills emitted, and ways to change where those polyfills come from, etc, is a big mess that isn't justified by the potential gains over simply including a normal [ES20XX] polyfill library in your script context.
And, as it's mentioned in that issue, emitting runtime code is a non-goal of TypeScript:
[非目标#] 6.提供其他运行时功能或库.而是使用TypeScript来描述现有的库.
[Non-Goal #]6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.
I'm guessing that some of the confusion comes from the fact that TypeScript does downlevel some language features when targeting earlier EcmaScript versions. The main criterion used when determining if a feature will be emitted as downleveled code or whether it needs a polyfill is syntax:
如果新语言功能在目标版本中从语法上来说无效，则它将降级，或者您将收到编译时警告.您不能强制填充无效的语法.例如，class Foo {}不是并且不能是有效的ES5代码...，因此在定位ES5时它将被转换为构造函数.
If the new language feature is syntactically invalid in the targeted version, then it will either be downleveled or you will get a compile time warning. You can't polyfill invalid syntax. For example, class Foo {} is not and cannot be valid ES5 code... so it will be converted into a constructor function instead when targeting ES5.
如果语言功能在目标版本中在语法上是合法的，则它将按原样发出而不会发出警告.因此，[1,2,3].includes(0)就语法而言是完全有效的ES5代码.假设有人向ES5引擎添加了Array.prototype.includes方法，那么它甚至可以在运行时运行.因此它是按原样发出的.请注意，当您在lib编译器选项中包含es2017时，您是在告诉TypeScript运行时将支持ES2017类型，因此没有编译时警告.添加类型库对运行时本身没有任何作用...因此，您需要负责填充/填充所需的任何内容.从编译器的角度来看，它无法处理您对运行时存在哪些方法撒谎的情况.显然，对于因运行时错误感到沮丧的人来说，这并不是什么安慰.
If, on the other hand, the language feature is syntactically valid in the targeted version, it will be emitted as-is with no warning. So [1,2,3].includes(0) is perfectly valid ES5 code in terms of syntax. Assuming that someone adds an Array.prototype.includes method to an ES5 engine, it will even work at runtime. So it is emitted as-is. Note that when you include es2017 in your lib compiler options, you're telling TypeScript that the runtime will support ES2017 typings, and so there is no compile-time warning. Adding typing libraries does not do anything to the runtime itself... so you're responsible for polyfilling/shimming anything you need. From the compiler's perspective it can't deal with the situation where you lied to it about what methods exist at runtime. Obviously that's not much consolation for someone frustrated by a runtime error, though.
哦，我想是的.
希望有帮助.祝你好运！
Hope that helps. Good luck!
这篇关于尽管tsconfig目标设置为ES5，为什么仍需要ES7/阵列polyfill的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
