René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design Meeting Notes, 1/13/2023","articleBody":"# Module-Format-Indicating Files Under Certain `--module` Targets\r\n\r\nhttps://github.com/microsoft/TypeScript/issues/50647\r\n\r\n* We added `.mts` and `.cts` to the list of extensions we recognize.\r\n    * They have a pretty straightforward meaning - ESM and CJS that emit to `.mjs` and `.cjs` respectively.\r\n* Other module resolution modes don't know that these files modes are special.\r\n    * But they don't choke on them - they don't treat them specially.\r\n    * That's good - opening a random `.mts` file in an editor shouldn't cause us to choke.\r\n    * But you can get contradictory outputs.\r\n* Issue uses these files with `--module esnext`\r\n    * Implies everything is ESM.\r\n    * But that means that `.cts` is interpreted as ESM\r\n* Two options\r\n    * Could make it a program-level error.\r\n    * Could allow the file extension to dictate emit options.\r\n        * `--module esnext` + `.cts` would emit to `.cjs` with CJS constructs.\r\n* Why not use `nodenext`?\r\n    * Confusing errors due to misconfigured packages.\r\n* Could take the position that these aren't allowed in the program with these settings.\r\n    * Has benefits like \"hey you are accidentally including a CJS file in your ESM program\"\r\n    * But it's a break.\r\n    * Also, what is the default behavior for the editor? It needs a default set of options.\r\n    * Maybe there's something here with `noEmit`?\r\n* What are our recommendations to users?\r\n    * What is the matrix of meaningful settings?\r\n    * 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.\r\n* Aside - our docs on these are confusing.\r\n    * Why do we need all these intermediate `esABCD` module modes?\r\n* What's `esnext` vs `nodenext`?\r\n    * `esnext` = ESM imports and exports\r\n    * `nodenext` = depends on `package.json` `type` field and file extension.\r\n* What if you just said \"use `--moduleResolution bundler`\" to these users?\r\n    * Well what is the `--module` option there?\r\n        * `esnext`?\r\n        * Well then what do you do with that `.cts`/`.cjs` file?\r\n    * What about `--module nodenext` + `bundler`?\r\n        * Well that seems okay - but it would be good if the file extension could override the resolution strategy.\r\n* Aside: `verbatimModuleSyntax` avoids many of these concerns. It removes the overhead of the emit target because what you see is roughly what you get.\r\n* Haven't heard any objections to the idea that file extensions should be able to override the emit target or resolution target.\r\n    * But does it make sense to emit an error?\r\n        * Why? This emits correctly. What is the problem with it?\r\n* What's our next step?\r\n    * We feel comfortable making file extension override the emit target.\r\n        * `--module` would only toggle the emit settings for `.ts` and `.tsx` files.\r\n        * Feels more controlled.\r\n* Really want to be able to come up with a simpler story here.\r\n    * We'd like to revisit this with docs.\r\n    * Before RC.\r\n    ","author":{"url":"https://github.com/DanielRosenwasser","@type":"Person","name":"DanielRosenwasser"},"datePublished":"2023-01-13T20:51:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/52229/TypeScript/issues/52229"}