Design Meeting Notes, 10/2/2020

[DanielRosenwasser]

Consistent Union Type Sorting

(sometimes referred to as "deterministic")

• Tools depend on type print-back, but union types are ordered by internal IDs assigned to types.
• Sometimes, the union 1 | 2 gets printed back as 2 | 1 because the numeric literal type 2 gets created first!
• Should we just sort them?
• Efficient way, inefficient way.
  • Efficient: Could find a reasonable sorting strategy
  • Inefficient: Print them individually, sort by string representation.
• Conclusion:
  • Wow, we actually are okay with committing to trying this???
  • Congrats community!

What goes in lib.dom.d.ts, exactly?

https://github.com/microsoft/TypeScript-DOM-lib-generator#what-are-the-typescript-teams-heuristics-for-prs-to-the-dom-apis

• We want to have an up-to-date lib.dom.d.ts, but we want to limit lib.dom.d.ts to features that are broadly implemented and stable.
• WHATWG keeps adding features in their spec, but no other browser adds those features - how do you determine what is "spec" vs. "immediate web reality" (or even "eventual web reality")?
• W3C takes a bit of time to adopt certain features, so that isn't enough for lib.dom.d.ts consumers.
• Today, 20-30 IDL files downloaded from WHATWG/W3C
  • What if the strategy was to just give the corresponding .d.ts file from each of these.
  • Maybe separately concat like today to create lib.dom.d.ts, but let people opt in individually?
    • Can take lib.dom.d.ts, or grab the individual declarations from @types.
• You can have TypeScript itself depend on @types/dom
  • But how do you depend on differing dependencies, one package relies on v1, TS relies on v2.
• Safe strategy is to break apart first, then consider @types.
• Then maybe could have lib.dom.actuallyhtml5.d.ts (exaggerated name), lib.dom.stable.d.ts, and then loop them all together in lib.dom.d.ts.
• Seems strange to make lib.dom.d.ts to have all the stuff - lots of web developers need to be careful to be maximally compatible. Want to know when browser X implements stuff, browser Y doesn't. Testing only in browser X reinforces this.
  • New features can be opt in if you need something.
  • Bleeding edge users may be okay with that.
    • Making default opt-out for footguns has been bad with @types, consider the same here.
• Can we even split? The generator is very complicated.
  • Speculative right now.
  • But have to see.
• Conclusion:
  • Need to investigate whether the DOM generation code can actually generate multiple files.

Getting TSServer Working in WebWorkers

#39656

• Have an alternate sys for these files.
• Currently only working in partial semantic mode.
• Logger: goes to the console, but need to have something less noisy.
• Otherwise, works!
• PR has instructions for getting it working.

void Properties are Optional

#38479

• Not type-safe to make value optional on IteratorResult<T>.

• Tried to add a conditional that checked if T was void, then made it optional.

  • Broke fp-ts, other stuff.

• Tried something else, broke almost nothing: void makes properties optional.

• void means "I won't witness this."

• Some argue this should be illegal.

  function f(): number | void {
    // ...
  }

• void in a return type only allows undefined or no explicit return value.

• Otherwise, void is "I will not witness this value"

• void needs to have consistent behavior between generators yield values and return values.

• But is consistency on this point more important than usefulness?

  • People keep messing up how void works.

• What's the difference between void and unknown?

  • At runtime, every function returns something.

• void | Promise<void> - kind of like hacky negated types

  • Either a Promise or something you should really never look at, but is not a Promise.

• We need a consistent viewpoint on what void is.

  • "We keep twerking it around".
    • [[I know they meant "tweaking", but I'm going to keep this in the notes because I thought it was funny.]]

• Another option:

  • undefined makes things optional
  • void should be switched out with undefined in implementations.
  • unknown in declarations for callback return position
  • Something along these lines - Ryan is willing to experiment.

• Relevant: missing

  • Design Meeting Notes: 10/20/2017 #19393
  • Design Meeting Notes, 1/19/2018 #21307

• Conclusion:

  • Experiment with variations so we can make an informed comparison between both options.

[orta]

/cc @saschanaz who I expect would be interested in dom discussions above

[saschanaz]

Emitting multiple files per IDL itself should be doable, but not sure about how the packages could be versioned.

Also what would happen when:

• A new spec emerges, say Foo. Browsers adopt it, so we add @types/webspec-foo.
• Spec authors conclude the spec is mature enough and then decide to merge it into HTML. (This does happen and is not rare.)
• Assuming that whole spec is merged, then we discontinue @types/webspec-foo. But users still use it, and some day HTML introduces changes to the merged types and that causes conflicts. How can we manage this?

Setting correct dependencies will also be important as IDLs does not have import statements, but theoretically it should be doable too.

[saschanaz]

WHATWG keeps adding features in their spec, but no other browser adds those features

I think microsoft/TypeScript-DOM-lib-generator#915 is the best solution for this. BCD tracks how many browsers have adopted features so we can use their data.

W3C takes a bit of time to adopt certain features, so that isn't enough for lib.dom.d.ts consumers.

Not sure this is a problem. In 2020 we generally get a spec first and then a feature, so I think it's not really an issue.