--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?

在编辑器中，tsconfig init 或隐式？
仅推断项目(编辑器)。
也许我们可以使用这些扩展的存在(可能不太可靠，因为有些项目多年来一直告诉人们在 web 上使用 mjs)或者一个 package.json 作为指示来交换编辑器中的隐式模块设置？
是的，我们可以将其作为上述更保守的替代方案。但我认为我们不能使用这些扩展的存在来切换隐式模块 解析 设置，因为我认为这可能是太大的变化(一个 mjs 或 cjs 文件导致我们在 package.json 中找到 "type": "module" 并突然抱怨无扩展名的导入，而实际上用户的目标是一个打包器或其他东西)

离题：使用Visual Studio 2022处理.cts/.mts文件的经验也非常有趣。

上下文来自推特：https://twitter.com/lukeshiru/status/1529243997809430529

@weswigham 你有什么关于合理行动的想法吗？当然，我们现在拥有的选项组合，以及我们可能考虑转向的任何选项，都是一种奇怪的虚构。
我甚至怀疑 .cts / .mts / .cjs / .mjs 文件是否应该放入一个单独的推断项目中，该项目确实有 --module nodenext --moduleResolution nodenext 😬。

概述可能的解决方案以讨论权衡：

• --module esnext 可能会回退到 --module commonjs 用于 .cts / .cjs 文件
• 我们可以更改默认的 --module 为 nodenext
• 我们可以将 .[cm][tj]s 文件放入一个单独的推断项目中，至少包含 --module nodenext
• 发明一种专门为推断项目的新模式，支持一些节点 next 解析功能和特殊文件扩展名，但不对像无扩展名的相对模块指定符这样的内容出错