Typescript: Introduce `module: es2020`

[saschanaz]

Search Terms

https://github.com/microsoft/TypeScript/blob/e8bf9584aa74aabfecb51a02edb13e3657508274/src/testRunner/unittests/config/commandLineParsing.ts#L112

Suggestion

Support module: es2020, as dynamic import() hit stage 4 as a part of future es2020 standard.

Use Cases

import("./mymodule.js");
// TS1323: Dynamic import is only supported when '--module' flag is 'commonjs' or 'esNext'
// `esnext` will unexpectedly enable features that might arrive after es2020.

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[fatcerberus]

Dynamic import is stage 4? Yay!

[saschanaz]

Dynamic import is stage 4? Yay!

https://github.com/tc39/proposals/commit/b04295ff4af51c143c62df62947ae7cb25759691#diff-79a53ca5c00fe0d90f18cd5237280da3 https://github.com/tc39/ecma262/pull/1482 👍

[RyanCavanaugh]

@weswigham @rbuckton thoughts?

[weswigham]

I, for one, appreciate the growing number of es module kinds. (However when someone says "I wanna use es modules" the answer just gets less and less clear with each iteration)

[fatcerberus]

There are only 2 kinds currently though? The kind that supports dynamic import and the kind that doesn’t. Are there other kinds of ESM that I’m unaware of?

Maybe a --enableDynamicImport flag would be easier to document and reason about...

[rbuckton]

Our standard practice would be to add an es2020 module kind, which would be the default for --target es2020 when no module kind is specified.

[weswigham]

There are only 2 kinds currently though? The kind that supports dynamic import and the kind that doesn’t. Are there other kinds of ESM that I’m unaware of?

The kind that supports export * as foo from "wherever" (currently stage 2 or 3) and the kind that don't. Also the kind that support top level await (currently stage 3) and the kind that don't.

I look forward to our many iterations of es modules, officially the _most complicated_ module system in JS, from a compatibility perspective (and none of the features are reasonably polyfillable at runtime since they're all syntactic). For comparison, we didn't need a different commonjs module target every year, at least 🤷‍♂

But @rbuckton is right - a module: es2020 paired with a target: es2020 is the way to go.

[fatcerberus]

That’s just a matter of what syntax it supports though, right? So the same complexity arguments apply to e.g. target and its yearly ES versions (and new syntax being added all the time). The basic ESM semantics at runtime remain the same.

There’s only a single “living standard” in reality, but TS’s job is made harder because it has to support downleveling, plus module resolution/loading is largely static so the features can’t be easily polyfilled. :frowning:

[fatcerberus]

I guess what I’m getting at is, would it be possible to have a single esm module type and then have the supported syntax be based on the value of target, transpiling where possible? ESM is part of the ECMAScript standard, so it’ll be versioned in tandem with the rest of JS.

This, IMO, would make a lot of the perceived complexity go away while still allowing you to use the yearly versions like es2020 if you wanted.