Possible breaking change: assigning array to 1-tuple

[amcasey]

Bug Report

🔎 Search Terms

dom, tuple, assignability

🕗 Version & Regression Information

Repros in 4.2 Beta and nightly

• This changed between versions 4.1.3 and 4.2 beta

Important caveat: The code was originally building against 4.1 and had polyfills for types that are in lib.dom.d.ts in 4.2.

⏯ Playground Link

TS 4.1.3 with polyfills: Playground

TS 4.2 beta with re-declaration of lib.dom.d.ts interface: Playground

💻 Code

interface ResizeObserverCallback {
  (entries: ResizeObserverEntry[], observer: ResizeObserver): void;
}

const resizeObserver = new ResizeObserver(([entry]) => {
  entry
});

🙁 Actual behavior

Argument of type '([entry]: [any]) => void' is not assignable to parameter of type 'ResizeObserverCallback'.
  Types of parameters '__0' and 'entries' are incompatible.
    Type 'ResizeObserverEntry[]' is not assignable to type '[any]'.
      Target requires 1 element(s) but source may have fewer.(2345)

🙂 Expected behavior

The fact that the repro depends on re-declaring a dom interface is suspicious, but the re-declaration appears to be identical, so it's not obvious to me why this error would be produced.

Also, note that the (as a result of sensible variance reasons), the lambda parameter is listed before the callback parameter on line 2 of the error and the types are in the opposite order on line 3 of the error. I found this confusing.

[amcasey]

@RyanCavanaugh suggested we should probably be using the contextual type ResizeObserverEntry[], rather than the expression type [ResizeObserverEntry].

[weswigham]

Multiple overloads -> multiple signatures contextually typing the expression -> no contextual type applied to the expression.

[amcasey]

@weswigham Even when the overloads are identical?

[weswigham]

getContextualSignature merges identical signatures across a union of types, but not identical signatures within a single type (getContextualCallSignature returns nothing for types with > 1 signature).

[RyanCavanaugh]

Given the root cause I don't think this merits documenting -- we fill in DOM signatures every release and while the downstream behavior here is surprising, it's not at all new.