TypeScript TSConfig CompilerOptions ES2017 Target and Lib

Question

I'm working on a TypeScript project and we're using ES2017 as the output target, as well as one of the libs, because it'll then go through Babel, and we want to support the latest feature set for whatever "Env" we're targeting in Babel.

Everything seems to work fine, so I'm not too worried about it. However, I don't know what's going on behind the scenes or what the "lib" option really does (other than tell my IDE what things I can do, like spread ops, Promises, etc.), and if it is more/less efficient to specify the highest output from TypeScript to then be compiled to a very specific target in Babel. This is going through WebPack, too, so we're taking advantage of tree shaking.

Second question is, when "ES2017" is included in the lib, does that include all features in ES2015 and ES2016 (in other words, is there any reason to include ES2015 and/or ES2016, with ES2017 in the list?)

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

As an aside, when targetting "last 1 Chrome version" in Babel "Env", it hardly does any transpiling at all, which is pretty exciting. We're just building prototypes, not production code, so we specifically add browsers we need to support when we need to support them, but almost never do anything that isn't the last 1 or 2 versions of Chrome.

Archpriest

Answer 1

Well looking at the actual implementation of the lib possibilities on the Typescript GitHub, it seems that ES2017 contains all of these packages:

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

And the es2016.d.ts contains the following references:

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

And finally es2015.d.ts references:

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

So it's safe to assume es2017 contains most ES functionality.

Although interestingly es6 is not included anywhere and provides it's separate file without any references. I don't really know how that works but I assume it's a separate combination of some of the things mentioned above.

EDIT:

I've done some more research on the es6 dilemma mentioned above and have posted my findings in a different question.

Marjana