TypeScript TSConfig CompilerOptions ES2017 Ziel und Lib

Question

Ich arbeite an einem TypeScript-Projekt und wir verwenden ES2017 als Ausgabeziel, sowie eine der Bibliotheken, weil es dann durch Babel gehen wird, und wir wollen Unterstützt die neuesten Funktionen für "Env", auf das wir in Babel abzielen.

Alles scheint gut zu funktionieren, also mache ich mir keine Sorgen. Ich weiß jedoch nicht, was hinter den Kulissen vor sich geht oder was die "lib" -Option wirklich tut (außer meiner IDE zu sagen, was ich tun kann, wie zB Ops, Promises, etc.), und wenn es mehr ist/weniger effizient, um die höchste Ausgabe von TypeScript zu spezifizieren, um dann zu einem ganz bestimmten Ziel in Babel kompiliert zu werden. Dies passiert auch durch WebPack, also nutzen wir das Tree Shaking aus. Die zweite Frage ist, wenn "ES2017" in der Lib enthalten ist, schließt das alle Funktionen in ES2015 und ES2016 ein (mit anderen Worten, gibt es einen Grund, ES2015 und/oder ES2016 aufzunehmen, mit ES2017 in der Liste?)?

)

{ 
    "compilerOptions": { 
    "target": "ES2017", 
    "module": "ES2015", 
    "moduleResolution": "Node", 
    "sourceMap": true, 
    "emitDecoratorMetadata": true, 
    "experimentalDecorators": true, 
    "forceConsistentCasingInFileNames": true, 
    "allowSyntheticDefaultImports": true, 
    "noEmitHelpers": true, 
    "importHelpers": true, 
    "pretty": true, 
    "alwaysStrict": true, 
    "lib": [ 
     "DOM", 
     "ES2017", 
     "DOM.Iterable", 
     "ScriptHost" 
    ], 
    "baseUrl": "./client", 
    "paths": { 
     "styles/*": ["./app/styles/*"], 
     "core/*": ["./app/core/*"], 
     "components/*": ["./app/components/*"], 
     "containers/*": ["./app/containers/*"], 
     "assets/*": ["./assets/*"], 
     "config/*": ["./config/*"] 
    } 
    }, 
    "files": [ 
    "./client/custom-typings.d.ts", 
    "./client/app/app.ts" 
    ] 
} 

Als Nebenwirkung, wenn "letzten 1 Chrome-Version" in Babel "Env" Targeting, es kaum Keinerlei transpiling überhaupt, was ziemlich aufregend. Wir erstellen nur Prototypen, nicht Produktionscode, also fügen wir speziell Browser hinzu, die wir unterstützen müssen, wenn wir sie unterstützen müssen, aber fast nie etwas, das nicht die letzten 1 oder 2 Versionen von Chrome ist.

Answer 1

Nun bei der tatsächlichen Umsetzung der lib Möglichkeiten auf dem Typescript GitHub suchen, scheint es, dass ES2017 all dieser Pakete enthält:

/// <reference path="lib.es2016.d.ts" /> 
/// <reference path="lib.es2017.object.d.ts" /> 
/// <reference path="lib.es2017.sharedmemory.d.ts" /> 
/// <reference path="lib.es2017.string.d.ts" /> 

und die es2016.d.ts enthält die folgenden Hinweise:

/// <reference path="lib.es2015.d.ts" /> 
/// <reference path="lib.es2016.array.include.d.ts" /> 

Und schließlich es2015.d.ts Referenzen:

/// <reference path="lib.es2015.core.d.ts" /> 
/// <reference path="lib.es2015.collection.d.ts" /> 
/// <reference path="lib.es2015.generator.d.ts" /> 
/// <reference path="lib.es2015.iterable.d.ts" /> 
/// <reference path="lib.es2015.promise.d.ts" /> 
/// <reference path="lib.es2015.proxy.d.ts" /> 
/// <reference path="lib.es2015.reflect.d.ts" /> 
/// <reference path="lib.es2015.symbol.d.ts" /> 
/// <reference path="lib.es2015.symbol.wellknown.d.ts" /> 
/// <reference path="lib.es5.d.ts" /> 

Es ist also davon auszugehen, dass es2017 die meisten ES-Funktionen enthält.

Obwohl interessanterweise ES6 ist nirgendwo enthalten und bietet seine separate file ohne Referenzen. Ich weiß nicht wirklich, wie das funktioniert, aber ich nehme an, es ist eine getrennte Kombination von einigen der oben genannten Dinge.

EDIT:

ich etwas mehr Forschung auf dem es6 Dilemma oben genannten getan haben und haben meine Ergebnisse in einem anderen question geschrieben.