Design Meeting Notes, 9/5/2025

[DanielRosenwasser]

Removing Fallback Behavior for package.json exports

#50762

• Started resolving from exports "more-correctly", but not really clear why things are going wrong.
• Now we at least can issue an error while also using the fallback.
• Much better now - but still quite a high number of breaks.
• One of the biggest is actually class-variance-authority.
  • See here.
• Typically the fix is to move the types condition ahead of the import condition.
• But a lot of things are just fundamentally broken because they rely on types being used for both import and require.
• One of the problems is that we assume index.mjs not having a corresponding .d.mts file implies that the file is untyped even if there are other conditions.
  • Really you would hope that there are fallbacks.
  • That might've been the original intent, but then there are all these properties around single-lookup behavior that throw a wrench in that. And at that point, why even have arrays values in exports?
• How do people solve .d.ts for ESM and CJS?
  • Used to need a tool for this, nowadays the advice is DON'T DO THIS because we have good CJS/ESM interop.
• Without dual publishing, how would you do this?
  • You would ideally not use conditions.
  • If you decide to emit to a different directory for each format, then you need types and then default, not types and import.
    • Great, another hazard.
• We should have a blog post "Stop Doing Dual Publishing".
• So what's the appetite for this?
  • Not by default. Too much pain for basically no benefit.
  • So flagged?
    • But who would want that?
    • arethetypeswrong does this.
      • The tool is the flag.
  • What if we shipped arethetypeswrong in the compiler?
  • Well what you want at least is a way to run arethetypeswrong as a consumer.
• These packages are pretty dubious, but we don't want to rock the boat if we don't need to.
• Possibly we revisit in the future, but it's not pressing.

const enum Declaration Erasure

microsoft/typescript-go#1632

• const enum declarations are still emitted in JS, despite preserveConstEnums
• Have a PR for it from @a-tarasyuk.
• But we decided to retain them in emit for a reason.
• So should we flip the default of preserveConstEnums to true?
• What use do you have with that?
  • Debugging via reverse-mapping, easy transpilation.
• Could insert a /* #__PURE__ */ comment to signal to minifiers to remove the enum.
• One idea is to flip the defaults and also drop the const in declaration files.
  • Avoids versioning issues.
  • The issue here is project references that expect to be inlined.
• If we changed the default, we'd do it in 6.0.
• Maybe the rewrite is not the right time - maybe 8.0?