Design Meeting Notes, 7/17/2020

[DanielRosenwasser]

Falsey<any> -> any, Falsey<unknown> -> unknown

#39529

function isThing(param: unknown): boolean {
    return param && typeof param === "object";
}

• Basically this sort of thing is unsafe because unknown could be a string or whatever.
• Ends up affecting lots of truthiness checks.
• Also not exactly clear when you end up with unknown is not assignable to Whatever
  • But you already get this sort of behavior for if param was typed initially as string or number.
• Does this happen only in strict mode? Or in all modes?
  • In non-strict mode we just take the right side of the expression; in strict mode, you get the error.
• So we have some concerns about the error, but this seems like the right behavior.
• It's a breaking change, so 4.1 bound.
• But happening!

More Accurate Checks in Conditional Types

#39577

• In conditional types, we decide whether to "evaluate" the conditional type based on whether the most restrictive and least restrictive instantiations will succeed and not succeed.
• But the way we track that is wrong because it compares with respect to the "wrong" container types.
• PR reintroduces a "definitely assignable" relationship.
  • Simplifies our codebase quite a bit.
• 2.5% increase in compiling material-ui
  • That codebase is a stress-tester for regressions on type relationship checking.
• We've had 9 releases where the current behavior has shipped until anyone realized.
  • Is the slowdown worth it?
• PR has a suggestion for a layered cache. Suggestion had no meaningful speedups. What about TypeScript Server Error (3.8.3) Debug Failure. False expression. #37810?
  • Didn't have any effect on material-ui, but was pretty nice on our compiler-with-union-nodes codebase.
  • Maybe combined they could work better?
• Note, MUI is not an outlier, it's representative of the React community.
  • The patterns around CSS properties.
  • Anything that uses styled components might see the same regressions.
• Revisit towards 4.1 timeframe. Could affect a lot of people, don't want to be risky.

Quoted vs Unquoted Numerically Named Keys in Declaration Files

#37292

class C {
    readonly lines = {
        '1': 'abc',
    };
}

• What should keyof C['lines'] be?
  • When we see the numerically named property, we say that it can be 1 or "1".
  • When we print this as a .d.ts, we only printed out the string representation.
• PR ensures the numeric keys are present.
• Will this cause big problems with Exclude and Omit?
  • What would you be excluding? "0"? "1"?
• Things that expect strings and someone wrote an incorrect Object.keys.
• Didn't see any code getting broken, but might not have enough tests.
• If your intent is to get only strings or whatever, you can use Extract<keyof T, string> or (keyof T) & string.
• Conclusion: keep exploring here.

Supporting Types in the npm CLI

npm/read-package-json#92

• npm has an RFC process
  • Have one for adding type information to the npm registry.
  • Make it unambiguous on the registry as to whether a package includes types.
• Have a PR on the npm CLI to stamp whether there's a TS or Flow types file "on the way up" when publishing.
• Yarn's search currently indicates whether packages are typed - npm's search does not. This would allow the npm search to work better.
• Why can't npm's search figure this stuff out on its own?
  • Yarn uses Algolia to figure things out, does local file system access.
• How does the exports list work?
  • This is the new "multi-main package" field that can support ES modules.
  • https://nodejs.org/api/esm.html#esm_exports_sugar
  • Unclear if there are issues yet.