Transformer Plugins

• Concept in the TypeScript API called customTransformers
  • You can provide transformers before and after for JS output files, and after declaration files.
• Can we support this via the tsc command?
• We released 5.0 recently, but it broke a lot of how people do patching.
• Main reason people do patching (Yarn aside) is doing custom output transformers.
• These transformers pass in the Program - are they effectively doing type-directed emit?
  • Is type-directed emit a bad thing?
  • You need an EmitResolver for something like runtime type-checks, or minification, or whatever.
  • [[Discussion on philosophy of "statically analyzable" emit vs. "type-directed" emit]]
  • Some of why type-directed emit is "bad" is because we don't have the full program.
  • Another is that we're not sound.
• TypeScript itself had to avoid type-directed emit due to these factors and out of trust - when you write JavaScript in TypeScript what you get is what you see!
  • But when you use a plugin, the problems are
    • They might be slow.
    • They might do the wrong thing, often because of unsoundness.
      • And when that happens, people may kvetch and we have to say "yeah we know, we said that you".
• If we're doing watch plugins, it feels like transformer plugins.
  • And then module resolution plugins?
    • 😬
• customTransforms have existed for over 5 years, always been an asymmetry (if not just annoying) that you have to use a bundler or write a wrapper for tsc.
• Feels like the safest plugins to most dangerous are transforms, watch, and module resolution.
  • Some feel the opposite.
  • Why?
    • Transforms are fairly linear. Watchers can bork state of the program, module resolution leads to an incorrect program, and most people don't know the real scope of what you need to support resolution correctly.
    • Other reasons: resolutions from Deno, Yarn, etc. would not fit into most resolution strategies.
• Proposal:
  • Build on the plugins array.
  • type is a new field for each plugin entry.
    • Maybe transform plugins get "type": "transform" or whatever.
    • Maybe Watch plugins get "type": "watch"
    • Try not to conflict with ts-patch or others who currently use plugins
  • First step - allow users to provide customTransformers.
  • All of this on the command line requires some new --allowPlugins flag.
• Come back to this at next meeting.

Type Argument Placeholders and Feedback

#26349

• Changing overload resolution broke a ton, so we backed off of the "partial type argument" thing.
• Lots of people watching Implement partial type argument inference using the _ sigil #26349 - but all with different needs.
• People saying "I have a type argument that never should be specified"
  • Translates to "We need an existential at this location"
• People really don't want users to write foo<SomeType, _, _, _> even if it's an improvement from foo<SomeType, VeryLongType, VeryLongType, VeryLongType>
  • Flow has existentials, Rust has impl trait types, etc.
  • But existentials act as something that adds quite a bit of work to every call.
  • Also, not full agreement here that everyone on the issue is looking for this feature.
• preferinfer?
  • Using type argument defaults means that we fall back to the default itself if it's not specified - so preferinfer says "no no no, the default isn't desirable. You want this thing to be optional, but to use inference as a fallback if it's not specified".
    • That's almost always the behavior you want.
  • New type param modifier to allow for partial inference based on signature declaration #53999
  • Switches internal compiler behavior, but doesn't have a strong type theoretic foundation.
• Feels like people want a local type alias.
  • But type alias wouldn't provide inference sites.
• We don't feel great about preferinfer at this moment - it feels like the scope is narrow.