Typescript: Add ES2017 Target

[yortus]

This is a request to make "target": "es2017" a valid compiler option. There is a list of finished features for ES2017 (all stage 4) that can be found on the TC39 Finished Proposals page.

Note that TypeScript _already_ supports "lib": ["es2017"] and includes lib.2017.d.ts, which declares the standard library features coming in ES2017, such as Object.values and Object.entries.

TypeScript also supports the two new syntactic features (async functions and trailing function commas), but with the current highest target (es6), these features are unconditionally downlevelled.

With an ES2017 target, async functions and trailing commas would be preserved in the transpiled JavaScript output, without downlevelling.

Async/await runtime support

Async functions are already implemented in both the V8 and ChakraCore runtimes. Node.js will support async/await natively (initially in v7.x with --harmony) when it updates to V8 5.4, expected by next month (i.e. October 2016).

Related issues

• #5361 Add ES2016 target discussion in that issue is largely about adding an evergreen ESNext target, which is a separate idea to this issue.
• #8838 There are no option to no transform async/await closed as duplicate of #5361. Would be solved by this issue, regardless of what happens with #5361.
• #9691 Allow Emitting Async Await Directly closed as duplicate of #5361. Would be solved by this issue, regardless of what happens with #5361.

[mhegazy]

A PR would be appreciated. Should be a small change.

[soft-labs]

Downlevel async/await is just a deal breaker for me right now. Is it happening anything about this issue?

[DanielRosenwasser]

@soft-labs downlevel async/await is available in our nightlies if you need. If your plan is to target ES201x to have Babel transform generators, then you can target ES2015 and do so.

[bootstraponline]

@soft-labs downlevel async/await is available in our nightlies

The point of this issue is to output async/await without downleveling.

With an ES2017 target, async functions and trailing commas would be preserved in the transpiled JavaScript output, without downlevelling.

[soft-labs]

@DanielRosenwasser Oh yes, I know. I need no transpilling at all, so I can use native chrome (is out now) and node with v8 5.4 native async/await implementation.

[pankleks]

I think everyone is waiting for TSC to have option to naively use async / await (without generation of __awaiter etc.).
Major browsers already support it, node should support it soon.
From functional perspective it does not bring anything extra, however debugging is nightmare with all of these __awaiter generated functions.

Any idea when this might be included in nighties?

[mhegazy]

Any idea when this might be included in nighties?

We would be happy to accept a PR for this.

[pankleks]

Hi - trying to use es2017 target in tsconfig.json but I get:

error TS6046: Argument for '--target' option must be: 'es3', 'es5', 'es6', 'es2015'

I'm using nightly: 2.1.0-dev.20161015

[yortus]

I think it was merged just after the cutoff time for the 20161015 nightly. Try tomorrow.

[pankleks]

Awesome!
Can't wait for this one:) thanks for the job you guys doing on that.

[imcotton]

Does #11942 counts missing in ES2017 target?

[mhegazy]

https://github.com/Microsoft/TypeScript/pull/12160/commits/7b9a42f9958b072f057d42d506b7e082ebf19974 adds a new --target esnext as well to get experimental features passed through.

[JD-Robbs]

Just wondering whether es2017 and esnext include the correct respective libs? I can see that tsc loads it in getDefaultLibFilename - but doesn't seem to work for me: the moment I change my target from es6 to es2017, my compiler is riddled with notices around console (TS2304:Cannot find name 'console'.) and some other standard types like XMLHttpRequest.

The code compiles fine - it's just that tsc complains and spits out loads of notices. Manually setting es2017 in the lib array doesn't make it go away.

[mhegazy]

@JD-Robbs, it does not include the dom, can you file a new issue for that.

[mhegazy]

specifying the lib explicitly in the tsconfig.json file should work though.

[JD-Robbs]

@mhegazy thank you very much indeed.

As you say, the following configuration works:

"target": "es2017",
"lib": [
  "es2017",
  "dom"
]

So - it's not an issue, I suppose.

[aluanhaddad]

It still seems like it should work if it works for es2015. I added the lib option manually but it would be nice to not have to do that.

[noinkling]

The above still seems to be an issue. I can't find where in the codebase this is determined.

[nblavoie]

Upgraded to Angular 5.0.0, still having the same issues described below :

{
  "compileOnSave": true,
  "compilerOptions": {
    "module": "commonjs",
    "outDir": "./dist/out-tsc",
    "baseUrl": "src",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es2017",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2017",
      "dom"
    ]
  },
  "angularCompilerOptions": {
    "preserveWhitespaces": false
  }
}

And running the command ng build output the following errors :

error TS6046: Argument for '--module' option must be: 'none', 'commonjs', 'amd', 'system', 'umd', 'es6', 'es2015', 'esnext'.
error TS5024: Compiler option 'lib' requires a value of type Array.

[mhegazy]

@nblavoie this issue is closed almost a year ago. I do not think this is what you are looking for. You might have better luck sharing this on StackOverflow.