Repository navigation
Infer ESM-compatible module setting for inferred projects in "type": "module" or .mjs/.mts files #46698
Description
Activity
I started writing some stuff to infer the module kind for inferred projects, but what would be the downside of having VS Code simply change its default for inferred projects to
esnext? Daniel Rosenwasser (@DanielRosenwasser) Wesley Wigham (@weswigham) thoughts?Reacted by Daniel Rosenwasser and Jimmy WärtingI think that would be fine - but it might make sense to also bump up the
targettoes2020now.Reacted by Andrew Branch and Jimmy WärtingMatt Bierner (@mjbvz), what are your thoughts on doing the following for inferred projects?
- set the
moduletoesnext - set the
targetoption toes2020
- set the
Not sure, what would be the impact of changing the
module? The current default iscommonjsI think our
targetalready defaults toes2020: https://github.com/microsoft/vscode/blob/e794a5444b93b08092167a206c69ad56f7a1d358/extensions/typescript-language-features/src/utils/tsconfig.ts#L31Assuming you also set
moduleResolution: nodeto make up for un-settingmodule: commonjsso you still get package specifier resolution,module: esnextis going to be a little wonky for TS files; it does things like disallowimport a = require("b")andexport = expr, while in exchange you allowimport.meta. The (upcoming)nodenextbehaviors (whereimport a = require("b")is always defined and allowed andexport = expris at least allowed in cjs targeting contexts) would be more broadly applicable, imo (and likewise allowimport.metain known-module contexts). Both would start allowing top-level await (in certain contexts), which is... maybe stable enough? It ships without flags in major runtimes, at least.The current default,
commonjs, is definitely our most stable default for modules, to be sure. It's probably also still the most broadly applicable for a random sample of files. I dunno, it's in some ways weird to have a "default" module system nowadays, when we live in a fracturing module ecosystem, where commonjs is being slowly drained of life by people separately trying browser native esm flavors, webpack and co esm flavors, deno esm flavors, and node native esm flavors. Still, I think cjs currently reigns supreme above them all in actual usage, so unless you wanted to be a trend-setter, I'm unsure if swapping the defaultmodulewould actually improve the experience for most people (and not just users on the cutting edge).When we’re talking about inferred projects, I think it makes sense to be as permissive as possible.
moduleprimarily impacts emit, and I don’t think it makes sense to think about emit without any configuration. I think disallowing ImportEquals and ExportEquals won’t be a problem for user code, but it might be a little annoying when you’re navigating into random node_modules .d.ts files, which use those syntaxes a lot more than non-ambient code. I do think node12 or nodenext would possibly be a better selection, but we need to wait until those are shipped and stable (and this issue can wait on that if needed).Can you just look at a file and detect if it use
importorrequire()export default fnvsexports = fnno package.json, tsconfig.json or jsconfig.json or vscode settings would be the best.
it does things like disallow
import a = require("b")andexport = exprI think disallowing ImportEquals and ExportEquals won’t be a problem for user code, but it might be a little annoying when you’re navigating into random node_modules .d.ts files, which use those syntaxes a lot more than non-ambient code
Oh wait, those are only errors in non-ambient code anyway. On second thought I think es2020 or esnext is a perfectly reasonable default.
We decided to try (via Matt Bierner (@mjbvz)) setting
moduletoesnextandmoduleResolutiontonodein an upcoming VS Code Insiders.- added a commit that references this issue
on Mar 9, 2022 I've update VS Code to use
module: esnextfor implicit projects by defaultReacted by Andrew Branch- locked as resolved and limited conversation to collaborators
on Oct 21, 2025
If you open a directory in VS Code with no tsconfig.json and start writing an
.mjsfile, you get an error that you can’t useimport.meta, which is obviously wrong and super annoying, and if you don’t want to add a tsconfig, there’s no way to fix this other thants-ignoreing it.The same goes for writing a
.jsor.tsfile covered by a package.json that has"type": "module".