Skip to content

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

Open
@andrewbranch

Description

@andrewbranch
Member

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.)

Activity

andrewbranch

andrewbranch commented on May 26, 2022

@andrewbranch
MemberAuthor
added
SuggestionAn idea for TypeScript
Domain: Node ESMLike ES Modules, but specific to Node.js support (cts, cts, mjs, mts)
on May 26, 2022
andrewbranch

andrewbranch commented on May 26, 2022

@andrewbranch
MemberAuthor

@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

andrewbranch commented on Jun 1, 2022

@andrewbranch
MemberAuthor

Outlining possible solutions to discuss tradeoffs:

  • --module esnext could fall back to --module commonjs for .cts/.cjs files
  • we could change the default --module to nodenext
  • we could put .[cm][tj]s files 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
weswigham

weswigham commented on Jun 1, 2022

@weswigham
Member

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

andrewbranch

andrewbranch commented on Jun 1, 2022

@andrewbranch
MemberAuthor

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)

ceztko

ceztko commented on Apr 22, 2023

@ceztko

Off-Topic: the experience of Visual Studio 2022 with .cts/.mts files is also very lacking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Domain: Node ESMLike ES Modules, but specific to Node.js support (cts, cts, mjs, mts)In DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @weswigham@ceztko@andrewbranch

        Issue actions

          Improve experience for .cts/.cjs files in inferred projects · Issue #49270 · microsoft/TypeScript