Design Meeting Notes, 5/31/2023

[DanielRosenwasser]

Inference Between Overloads

#54448

• We infer signatures from the "bottom up"
• If the source has more signatures than the target, we start at the bottom and infer pairwise between them until we run out of target signatures.
• When the source has fewer signatures, we infer just from the bottom; but when we run out of source signatures, we just fall back to the constraints when we run out of source signatures.
• Why do we match pairwise?
  • In cases where we are inferring between a type and its instance, they really should
• Idea - when we run out of source signatures, jump back to the bottom signature (usually the broadest one), and infer from that one for all remaining target signatures.

  • In other words, if S has signatures

    A(...): ...
    B(...): ...
    C(...): ...
    

    and T has signatures

    D(...): ...
    E(...): ...
    F(...): ...
    H(...): ...
    I(...): ...
    

    what will happen is we will make the following inferences

    C -> I
    B -> H
    A -> F
    
    (and here's the new part)
    
    C -> E
    C -> D
    

• Pointed out that an Overloads helper type is affected.
• Must review.

Guidance and Actions For Publishing ESM Packages (sometimes with CJS)

• Very hard to publish types for modules in Node.

• Harder to do dual publishing of ESM and CJS.

• Very confusing - that's why Andrew made https://arethetypeswrong.github.io/

• Why don't we look at the output files for "type": "module"?

  • One idea - but there's a question of "should dual publishing even be done?"

• Should we even be supporting this pattern? Has hazards.

  • Feels like people need to fix the hazard, and fixing the hazard is itself more of a hazard; so supporting it seems like a must, no?

• The workarounds are still possible.

  • Hard to say "TypeScript itself would switch over to solely ESM as its emit mode".

• Aside-ish - --build mode is an orchestrator that one would hope could do this as well.

  • Related: No way to use composite project where outDir is determined by build tool #37378

• So this idea of figuring out details from output files (e.g. using outDir), is a bit of a break, but it is arguably a correctness fix.

• This all feels like the same problem as React Native running their builds multiple times too.

• Whatever we do here, feels like --build mode should be treated as a first-class citizen.

  • The scenario could be modeled by separate ESM and CJS tsconfig.*.jsons, and a solution-y tsconfig.json that references both of them.
  • There are problems of which tsconfig project do we primarily work off of in the language service - would have to really think about those.
    • Could prioritize ESM etc. in the project/session manager.

• Could instead have a concept of config profiles

  {
      "compilerOptions": {
          // ...
      },
      "configs": {
          "base": {
              "compilerOptions": {
                  // ...
              }
          },
          "node": {
              "compilerOptions": {
                  // ...
              }
          },
          "dom": {
              "compilerOptions": {
                  // ...
              }
          },
      }
  }

Transpilation/Compilation Off-Thread

#54461

• Do we need the binder to emit a file?
  • Yes - certain flags necessary for transforms, scope resolution, etc.
• Do we need the checker?
  • Mmmmmmaybe - seems like yes today.
  • Questionable.
  • Uses EmitResolver today, which basically relies on TypeChecker.