2019 (original) (raw)

`.mjs` Input Files

Node.js shipped module support recently
How's this work?
- In the Node runtime, as a CommonJS consumer, you can't interact with ESM at all.
- require always does a CJS resolution
- In a module, you can only import other modules, and they need to have extensions.
Idea: if what Node has today is the best that it will ever deliver...
- We'd have to redo basically everything in the CJS resolution scheme we do.
- We'd need to add .mjs resolution, but error on that.
- There will need to be a module format output.
- Also, import(...) would...need to not be imported.
Wait, why would you want any of this?
- You want to migrate consuming code (?)
Should we emit .mjs files?
- Shouldn't emit .ts files to .mjs files because that'd be a massive breaking change.
- Need a new module field?
- Need .mts and .cts?
  * .mtsx and .ctsx?
  * .d.mts and .d.cts?
- This is absolutely unreasonable.
  * Need to be able to disambiguate format of the original inputs.
  * Could it be in-band?
  * File extensions mean you don't need to read the file contents.
As long as we don't rewrite imports (and we won't because it's error prone and requires whole-program knowledge), then we need the disambiguators.
Take the following example

foo/package.json  
    foo/index.js   (this is ESM)  
    foo/index.cjs  (this is CJS)

require("foo") breaks because it'll resolve to foo/index.js
import "foo" doesn't work because it won't resolve to /index.js because Node thinks it's too magical for ESM.
This logic is extremely complex.
- "The combinatorics of this are extremely absurd."
- Can we come up with a smaller set of what is supported?
  * By doing that, it provides a prescriptive direction for users who ask "how do I write ES modules in Node and TypeScript?"
- But have to be smart about what we "leave on the table" and what that breaks.
  * Also want to leave things open for later additions.
Conclusion:
- .mjs in an import path is doable long-term, but not
- Node ESM support as a whole will need to be scoped out.
  * .mjs output is troublesome.

We're not rewriting paths.
- Not now, not tomorrow, not ever.
So is fixing this just a matter of relaxing the check?
- Sounds like it.
- But the check stops people from shooting themselves in their feet, so don't want to just confuse people more.
Unclear what the original use-case really is. Linked issues have very different goals/use-cases.
- Proposal: emit files without .ts extension to get custom file extension #30076
  * [[wat.bmp]]
It sounds like the only use-case is deno
- So "moduleResolution": "deno"?
- Uh, but what's your emit??
- How do you deal with https:// paths?
  * Maybe don't.
  * Can simulate this with path mapping/import maps.

What are the problems with pnp?
- Executes arbitrary .js file.
- The defaults make little sense in the editor - means that users need to configure their editors to load tsserver with yarn. Very opt-in.
- Also, while guidance is to stick to one version of package manager, users sometimes mix/match package managers and different versions.
- Kind of hard to be sure what doing the right thing means here that doesn't require the same level of configuration as an LS plugin that overrides resolution