Should target: es2020 set module: es2020 by default?

[saschanaz]

From #44656

Should this function return ModuleKind.ES2020 and ES2022 following the target version? It seems #33893 missed this, and I wonder this needs to be fixed.

TypeScript/src/compiler/utilities.ts

Lines 6035 to 6039 in 5afe42e

	export function getEmitModuleKind(compilerOptions: {module?: CompilerOptions["module"], target?: CompilerOptions["target"]}) {
	return typeof compilerOptions.module === "number" ?
	compilerOptions.module :
	getEmitScriptTarget(compilerOptions) >= ScriptTarget.ES2015 ? ModuleKind.ES2015 : ModuleKind.CommonJS;
	}

[dnalborczyk]

on a similar note regarding #44656

shouldn't top-level-await only be available when the target is set to ES2022 (doesn't exist yet) or higher/ESNext incl. module set to ES2022 or higher/ESNext (above PR). I personally would assume yes.

nm, I got it mixed up.

[saschanaz]

I think that's a different issue and should be filed separately 🤔

[sandersn]

@weswigham has the way that target maps to module changed? Above it looks like anything about ES2015 maps to ES2015 modules.

[weswigham]

I don't think so? The new node module modes imply some target modes if it's unset, but I don't think anything else has changed.

[jimmywarting]

thinking there should be a target option in vs code itself...
not everyone use typescript... i use vanilla javascript. if no tsconfig/jsconfig is available then it should assume esnext i.m.o.

don't assume that you know what the target the developer is developing for, i'm getting red lines about top level await everywhere
i wish i did not have to add a tsconfig.json just so i can get rid of this annoying error messages with checkJS turned on

[saschanaz]

thinking there should be a target option in vs code itself...

Well, jsconfig exists solely for that purpose.