Design Meeting Notes, 4/12/2024

[DanielRosenwasser]

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