Improve experience for .cts/.cjs files in inferred projects

In https://github.com/microsoft/TypeScript/issues/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.)

[andrewbranch]

@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]

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)