TypeScript TSConfig CompilerOptions ES2017 Target и Lib

Я работаю над проектом TypeScript, и мы используем ES2017 в качестве цели вывода, а также одну из библиотек, потому что затем она будет проходить через Babel, и мы хотим поддерживать последний набор функций для любого «Env». мы нацелены на Вавилон.

Вроде все работает нормально, так что особо не переживаю. Однако я не знаю, что происходит за кулисами или что на самом деле делает опция «lib» (кроме того, что я сообщаю своей IDE, что я могу делать, например, распространять операции, промисы и т. д.), и если это больше/ менее эффективно указывать максимальный вывод из TypeScript для последующей компиляции в очень конкретную цель в Babel. Это также проходит через WebPack, поэтому мы используем встряску дерева.

Второй вопрос: когда «ES2017» включен в библиотеку, включает ли она все функции ES2015 и ES2016 (другими словами, есть ли причина включать ES2015 и/или ES2016 с ES2017 в список?)

{
  "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"
  ]
}

Кроме того, при нацеливании на «последнюю версию Chrome» в Babel «Env» он почти не выполняет транспиляцию, что довольно интересно. Мы просто создаем прототипы, а не рабочий код, поэтому мы специально добавляем браузеры, которые нам нужно поддерживать, когда нам нужно их поддерживать, но почти никогда не делаем ничего, кроме последних 1 или 2 версий Chrome.


typescript babeljs ecmascript-6 tsconfig ecmascript-2017
person Community    schedule 22.03.2017    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Глядя на реальную реализацию lib возможностей на Typescript GitHub, кажется что ES2017 содержит все эти пакеты:

/// <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" />

И es2016.d.ts содержит следующие ссылки:

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

И, наконец, ссылки на es2015.d.ts:

/// <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" />

Поэтому можно с уверенностью предположить, что es2017 содержит большую часть функций ES.

Хотя интересно, что es6 нигде не включен и предоставляет отдельный файл без ссылок. Я действительно не знаю, как это работает, но я предполагаю, что это отдельная комбинация некоторых вещей, упомянутых выше.

ИЗМЕНИТЬ:

Я провел еще несколько исследований дилеммы es6, упомянутой выше, и опубликовал свои выводы в другом вопрос.

person Vigidis    schedule 09.05.2017