Design Meeting Notes, 8/29/2025

[DanielRosenwasser]

Module resolution errors that can happen when migrating from --moduleResolution node10 to bundler

• Deprecate, remove --moduleResolution node10 #62200

• Deprecate --moduleResolution node10 #62338

• Node10 deprecation fixes DefinitelyTyped/DefinitelyTyped#73574

• Only 2 external dependencies are broken - these are the most interesting ones, because those are "outside" of a user's control.

  • dotenv and glaze
  • dotenv has already been fixed in recent versions

• arethetypeswrong has been used to analyze popular dependencies that are importable by node10 but not in bundler.

  • 32 packages out of a bit over >4000 (less than 1%)

• The issue is almost always due to looking at types/main instead of exports.

  • But the problem is that exports is often "wrong" because the exports don't have a corresponding .d.*ts
  • So these are broken under node16+ and bundler.

• In these cases, TypeScript 5.x actually gives a good error message that the main or types field is right but exports is wrong and that you should file an issue or upgrade.

  • Might have broken this in latest versions?
  • But we don't actually use main/types as the fallback.

• Can we just send PRs to help out?

  • Maybe - some packages published like ~3 years ago
  • But some just a few days ago.
  • Maybe could just file issues.

• Do we need a flag to just use the fallback with no error?

  • That flag is just --moduleResolution node10 + --ignoreDeprecations in TS 6.0.
  • But that "strands you" on 6.0.
  • Using the fallback allows you to use // @ts-ignore as well!
    • See below on this.

Related: Fallback behavior for package.json exports

#50762

• 76/2000 - over 3%, but @Andarist filed many issues or fixed them.
• arethetypeswrong can detect this and make it easy to print out the fixes.
• Can't do this one in 6.0 maybe.
• Could maybe do this flagged?
  • Opt-in, or opt-out/?
• 7.0 is the opportunity to improve this.
• Could do the same thing with a fallback where people can // @ts-ignore.
  • But these issues can happen in transitive dependencies as well.
  • The same is actually true of the above for people forced onto bundler - but they have a stepping stone with 6.0.

Conflicts on modifiers for mapped keys

#62318

• What should happen to modifiers when a mapped type remaps multiple input keys to the same output key?
• Already discussed unioning behavior over years ago at Design Meeting Notes, 8/28/2020 #40309
• If we already have behavior to "union" the types, we should kind of replicate the behavior we have for objects there with readonly and optionality.
  • Idea is to prioritize the "read" view and be restrictive. If one is readonly, the resulting property is. If one is optional, so is the resulting property.
• abstract?
  • Gets dropped altogether by mapped types.
• Separate get/set?
  • We just use the get type.