Update lib for base/dom TS configs to target es2020

[BPScott]

Description

Not having definitions for standard es features beyond es2108 is a bit old-school. The cool kids want to use Array.flat() :p

We expect any TS that we write shall be compiled through babel which shall transpile any modern features that are not yet supported by the consuming app/lib's targets, so I'm feeling ok with being being fairly modern with with our lib definition availability.

This Pr updates the lib definitions so both the base and dom configs target "es2020". I believe this option was added in TS 3.5 which is sufficiently long ago (the pr that added it is from April 2019, and 3.5 was released May 2019).

esnext.asynciterable is removed because this functionality was standardised and is included as part of es2018 (which is in turn included by es2020).

Bonus questions

When comparing the difference between dom.json and base.json:

Base has "lib": ["dom", "es2020"]
Dom has: "lib": ["dom", "dom.iterable", "scripthost", "es2020"]

Why's dom in base.json? If that's important then should we be sticking dom.iterable/scripthost in base.json too and just remove the lib defiinition from dom.json?

Type of change

• typscript-configs Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have added a changelog entry, prefixed by the type of change noted above (Documentation fix and Test update does not need a changelog as we do not publish a new version for these changes)

[kaelig]

💅

Suggested change

	Increased the target and lib definitions to es2020 in both `base.json` and `dom.json`. This allows for a greater range of standard features to be defined and used. We expect typescript will be ran through Babel to downlevel/polyfill all features required for your target environment [[#239](https://github.com/Shopify/web-configs/pull/239)]
	Increased the target and lib definitions to es2020 in both `base.json` and `dom.json`. This allows for a greater range of standard features to be defined and used. We expect TypeScript will be ran through Babel to downlevel/polyfill all features required for your target environment [[#239](https://github.com/Shopify/web-configs/pull/239)]

[kaelig]

How about setting it to ES2021? Unless a patent-related objection happens over the next few weeks (unlikely), it'll become a standard in its current form very soon (June).

[kaelig]

ES2017 is still the best compilation target for modern browsers (supported by 95% of user agents), as it can be served without further transpiling using <script module src="..."></script>.
Then, apps who really want to support the additional 5% of browsers can transpile that first target into ES5, and serve it using <script nomodule src="..."></script>.

What I'm trying to say is that by keeping the target to ES2017, we're removing the need for a transpiler such as babel in most cases.

What am I missing here?

[BPScott]

We don't want tsc as part of our build chain, babel (or in a potential future esbuild) for single file transpilation is much better suited to our needs as they allow finer grained transpiling based on browser (/node) support of single features rather than whole standard versions.

Ideally tsc should only be used for type-checking, and we use something else to to builds. Thus this target doesn't really do anything, I'm just setting it here to match the lib value.

[kaelig]

Thank you, that makes sense!

[BPScott]

How about setting it to ES2021? Unless a patent-related objection happens over the next few weeks (unlikely), it'll become a standard in its current form very soon (June).

The es2021 target was merged in march this year and thus it's not in a currently released version of typescript (unless you count the 4.3 beta). es2020 is supported in existing ts versions