Repository navigation
Improve experience for .cts/.cjs files in inferred projects #49270
Description
Activity
Context came from Twitter: https://twitter.com/lukeshiru/status/1529243997809430529
Wesley Wigham (@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/.mjsfiles should go into a separate inferred project that does have--module nodenext --moduleResolution nodenext😬.Reacted by Lou CyxOutlining possible solutions to discuss tradeoffs:
--module esnextcould fall back to--module commonjsfor.cts/.cjsfiles- we could change the default
--moduletonodenext - we could put
.[cm][tj]sfiles into a separate inferred project with at least--module nodenext - invent a new mode specifically for inferred projects that supports some nodenext resolution features and special file extensions but doesn't error on stuff like extensionless relative module specifiers
--module esnext could fall back to --module commonjs for .cts/.cjs files
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.
we could change the default --module to nodenext
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.
we could put .[cm][tj]s files into a separate inferred project with at least --module nodenext
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?
In the editor, tsconfig init, or implicitly?
Inferred projects (editor) only.
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?
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)Off-Topic: the experience of Visual Studio 2022 with .cts/.mts files is also very lacking.
In #46698, we updated VS Code’s default
modulesetting for inferred projects to beesnext. Now that we have.ctsand.cjsfiles floating around, we ideally ought to allow the former to use import/export assignment syntax, and forbid both from usingimport.meta. Now that--module nodenextis 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
--moduleResolutionfor inferred projects which is stillnode. IIRC, we may need changes to set theimpliedNodeFormatof.cts/.cjsfiles even whenmoduleResolutionis not one of the new modes, or we may need some other strategy to just silence some of these errors in.ctsfiles under--module esnext.)