Open
Description
In #46698, we updated VS Code’s default module
setting for inferred projects to be esnext
. Now that we have .cts
and .cjs
files floating around, we ideally ought to allow the former to use import/export assignment syntax, and forbid both from using import.meta
. Now that --module nodenext
is out, that may be a better default that gets us most or all of the way there.
(Note that I’m not suggesting a change to the default --moduleResolution
for inferred projects which is still node
. IIRC, we may need changes to set the impliedNodeFormat
of .cts
/.cjs
files even when moduleResolution
is not one of the new modes, or we may need some other strategy to just silence some of these errors in .cts
files under --module esnext
.)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
andrewbranch commentedon May 26, 2022
Context came from Twitter: https://twitter.com/lukeshiru/status/1529243997809430529
andrewbranch commentedon May 26, 2022
@weswigham do you have ideas on what a reasonable course of action would be? Of course, the combination of options we have now, and any that we might consider moving to, is a bizarre fiction.
I almost wonder if
.cts
/.mts
/.cjs
/.mjs
files should go into a separate inferred project that does have--module nodenext --moduleResolution nodenext
😬.andrewbranch commentedon Jun 1, 2022
Outlining possible solutions to discuss tradeoffs:
--module esnext
could fall back to--module commonjs
for.cts
/.cjs
files--module
tonodenext
.[cm][tj]s
files into a separate inferred project with at least--module nodenext
weswigham commentedon Jun 1, 2022
That's pretty close to "esnext should become nodenext" - just missing dynamic import retention in cjs format files and js formats determined by scope package files.
In the editor, tsconfig init, or implicitly? I don't think we've ever changed an implicit default compiler option yet, but maybe adjusting the editor defaults works, since we already did it once.
Hm, this would be a bad experience for people actually using node (and thus most likely to use these extensions), as their js files and new extension files wouldn't be loaded into the same project, when they would want them to be.
Maybe we could use the presence of these extensions (maybe less reliable since some projects were telling people to use mjs on web for years) or a package.json as an indicator to swap the implicit module setting in the editor?
andrewbranch commentedon Jun 1, 2022
Inferred projects (editor) only.
Yeah, we could do that as a more conservative alternative to the above. But I don’t think we can use the presence of these extensions to switch the implicit module resolution setting, as I think that might be too dramatic of a change (one mjs or cjs file causes us to find
"type": "module"
in the package.json and suddenly complain about extensionless imports when in fact the user was targeting a bundler or something)ceztko commentedon Apr 22, 2023
Off-Topic: the experience of Visual Studio 2022 with .cts/.mts files is also very lacking.