Repository: TypeScript
Issue: Design Meeting Notes, 4/12/2024
Labels: Design Notes

# Problems with `__esModule` marker in JS/TS mixed `node16` environemnt

#58127

* Scenario: someone writes a `.cjs` file, it uses "native" CJS syntax, and uses TypeScript to transform it.
    * TypeScript compiles it to include all the ESM boilerplate, including defining an `__esModule` property.
        * This is incorrect for a CJS-intended module because these are supposed to typically importable as defaults but not necessarily have named imports.
    * From TypeScript's perspective, `cjs` files are allowed to use ESM syntax, and when you compile that away that should put you into an "interop style" mode.
        * That is the only time it should be okay to generate the `__esModule` marker.

# Supporting No-Probe Resolution

https://gist.github.com/lucacasonato/7de60c3cebcfc60aa3a644ac43762fd3

https://deno.com/blog/how-we-built-jsr#building-a-modern-publishing-flow-aka-say-no-to-probing

* Most TypeScript resolution modes probe for different file extensions given a module specifier.
* Deno/JSR specifically wants to avoid probing because doing so is expensive over the network.
* Have some suggestions - idea is people should be able to write a `.js` specifier, but have it either:
    * have an annotation on how to really resolve to the `.d.ts` file from the importer.
    * have it unambiguously resolve to a corresponding path, but then the imported file provide means to redirect to another `.d.ts` file.
* Also, have something for JSX which is where to look up the types of the JSX factory.
* Declaration emit would be able to replace all the real paths with file-local redirects.
* The concept of JSR is really appealing from an end-user perspective.
* Is declaration emit supposed to sub in the overriding path?
    * Feels like yes.
* Doesn't this process make things less parallelizable? i.e. two probes for JS and TS can resolve simultaneously instead of requiring hops.
    * Possibly.
* If one resolves a path to a module in the JS file, don't you need to run something to have resolved in the first place? Can't you set up import conditions for this?
    * Possibly? Requires fetching a resolution map. Could have multiple in a package.
* How do browser import maps work here?
    * There are tools that generate these.
* How does probe-less serve users well again?
    * For a Node.js user, you can avoid some probing.
    * For a Deno user, things just work with no slow network probing if they decide to use a 
* Possible issue: `tsconfig.json` brings every `.ts` and `.js` file in a folder.
    * JS and declaration files are side-by-side.
    * Today's resolution always prioritizes `.d.ts` file.
    * However, with this scheme, you must always load up the JS file.
        * Yes, but this is part of the new resolution mode.
        * But it's not just a new resolution mode, the hope is to incorporate this into every module resolution mode.
            * Oh. Yeah, that's bigger!
            * Don't necessarily need to parse out the entire file to do this.
* We have some precedent for AMD module specifier `/// <reference />`.
* For import overrides, we would generally prefer an import attribute or something.
    * Kinda funky since you need some way to express that it needs to be droppable.
    * Could do:

      ```
      with {
        declare types: "..."
      }
      ```

      ```
      with {
        type types: "@types/type.d.ts"
      }
      ```
        * (half joke!)
* We might need some more clarification on the scneai