Typescript: Docs: Difference between esnext, es6, es2015 module targets

[bcherny]

Search Terms

esnext, es6, es2015, module, tsconfig, tsconfig.json, difference, document

Suggestion

It would be great if this can be documented. On the face of it, the output for all three seems to be identical.

Related: It would also be nice to document why targeting module: "none" when your code is a module (ie. uses ES2015 imports/exports) generates CommonJS-compatible code instead of exporting to globals as "none" seems to imply.

[DanielRosenwasser]

To just answer the question, the difference is that import() expressions are understood in esnext, but not in es2015 (and as of TypeScript 2.9, import.meta is only understood with esnext).

I guess you could possibly expect an es2019 module target for both.

[mhegazy]

in addition to what @DanielRosenwasser mentioned, esNext is just a place holder for features that are on the standard track but is not in an official ES spec yet. e.g. import.meta and import() expressions. as TC39 adds these features to a versioned spec, we will add a new --module ES20** to reflect that.

Also es6 === es2015.

[qm3ster]

Is there a place where I can see the list of https://github.com/tc39/proposals syntax supported?
(As opposed to module target or libs.d.ts?)

[zoltan-nz]

You can find all the libs and supported features in this folder: https://github.com/Microsoft/TypeScript/tree/master/lib

[gilamran]

The only place that I found for understanding TS support is here, but this table is misleading... "red" doesn't mean that TS doesn't support the feature, it means that it doesn't run on previous version of JavaScript... yea, misleading.

Can we create a similar solution for TS, but with real supported/unsupported table? (With relation to the target)

[ayqy]

Is there someone who can give a detail explanation for module: "none" ?
ref: Difference between typescript module “None” and “CommonJS”

[vegerot]

Is targeting ESNext or module ESNext stable for long term releases? What if I want import() but also want stability?

[Mikilll94]

@vegerot
Any answer to this question?

[vegerot]

I wish

[DanielRosenwasser]

If you're looking for stability, you may want to hold off on using --target esnext unless you're piping the output through another compiler that supports newer ESNext syntax like Babel. If a feature is only available under ESNext, you'll likely need to wait until it is clear which version of the ECMAScript standard it will be added to.

[vegerot]

If, say the end result we send to users is ES2016 compatible (say, through Babel), does it make sense to target ES2016 and then pipe through the other compiler? Or to target ESNext and pipe it through the other compiler (assuming the other compiler supports ESNext)?

[DanielRosenwasser]

If you're targeting a minimally ES2016 environment (most modern browsers, most recent versions of Node) then there's no need to pipe through Babel except for auto-polyfills.

If you need auto-polyfilling, emit to ESNext and pipe through Babel.

If not, just emit to ES2016 with TypeScript.