Design Meeting Notes, 1/13/2023

[DanielRosenwasser]

Module-Format-Indicating Files Under Certain --module Targets

#50647

• We added .mts and .cts to the list of extensions we recognize.
  • They have a pretty straightforward meaning - ESM and CJS that emit to .mjs and .cjs respectively.
• Other module resolution modes don't know that these files modes are special.
  • But they don't choke on them - they don't treat them specially.
  • That's good - opening a random .mts file in an editor shouldn't cause us to choke.
  • But you can get contradictory outputs.
• Issue uses these files with --module esnext
  • Implies everything is ESM.
  • But that means that .cts is interpreted as ESM
• Two options
  • Could make it a program-level error.
  • Could allow the file extension to dictate emit options.
    • --module esnext + .cts would emit to .cjs with CJS constructs.
• Why not use nodenext?
  • Confusing errors due to misconfigured packages.
• Could take the position that these aren't allowed in the program with these settings.
  • Has benefits like "hey you are accidentally including a CJS file in your ESM program"
  • But it's a break.
  • Also, what is the default behavior for the editor? It needs a default set of options.
  • Maybe there's something here with noEmit?
• What are our recommendations to users?
  • What is the matrix of meaningful settings?
  • Even if you have the matrix, what do you do in the "no man's land" cases? That's part of what's being discussed here.
• Aside - our docs on these are confusing.
  • Why do we need all these intermediate esABCD module modes?
• What's esnext vs nodenext?
  • esnext = ESM imports and exports
  • nodenext = depends on package.json type field and file extension.
• What if you just said "use --moduleResolution bundler" to these users?
  • Well what is the --module option there?
    • esnext?
    • Well then what do you do with that .cts/.cjs file?
  • What about --module nodenext + bundler?
    • Well that seems okay - but it would be good if the file extension could override the resolution strategy.
• Aside: verbatimModuleSyntax avoids many of these concerns. It removes the overhead of the emit target because what you see is roughly what you get.
• Haven't heard any objections to the idea that file extensions should be able to override the emit target or resolution target.
  • But does it make sense to emit an error?
    • Why? This emits correctly. What is the problem with it?
• What's our next step?
  • We feel comfortable making file extension override the emit target.
    • --module would only toggle the emit settings for .ts and .tsx files.
    • Feels more controlled.
• Really want to be able to come up with a simpler story here.
  • We'd like to revisit this with docs.
  • Before RC.