🤖 User test baselines have changed

[typescript-bot]

Please review the diff and merge if no changes are unexpected.
You can view the build log here.

cc @weswigham @sandersn @mhegazy

[DanielRosenwasser]

There are really only 19 unique new issues, but they are clearly impactful and indicative of much broader breaks.

#	Error message
0	Property 'reason' does not exist on type 'CancelToken'.
1	Duplicate identifier 'CSSRule'.
2	Duplicate identifier 'Comment'.
3	Duplicate identifier 'Event'.
4	Duplicate identifier 'Position'.
5	Duplicate identifier 'Request'.
6	Duplicate identifier 'Window'.
7	Property 'style' does not exist on type 'HTMLDivElement'.
8	Property 'style' does not exist on type 'HTMLElement'.
9	Property 'setImmediate' does not exist on type 'Window'.
10	Property 'logicalXDPI' does not exist on type 'Screen'.
11	Property 'deviceXDPI' does not exist on type 'Screen'.
12	Property 'logicalYDPI' does not exist on type 'Screen'.
13	Property 'deviceYDPI' does not exist on type 'Screen'.
14	Property 'offsetTop' does not exist on type 'Element'.
15	Property 'style' does not exist on type 'Icon'.
16	Type '[CSSStyleSheetHeader, any[]][]' is not assignable to type 'CoverageInfo[]'.
17	Type '(a: SortableDataGridNode, b: SortableDataGridNode) => number' is not assignable to type '(arg0: NODE_TYPE, arg1: NODE_TYPE) => number'.
18	Type 'NODE_TYPE[][]' is not assignable to type 'ViewportDataGridNode[][]'.

[sandersn]

Here's some of the reasons for the breaks. I think it's mostly (all?) down to the recent update to the generated d.ts files.

[sandersn]

I am really unsure what is going on here. setImmediate and clearImmediate come from @types/node and shouldn't have anything in the type space because they are functions (although setImmediate has a merged namespace, it's a value namespace).

[sandersn]

If there's no @types/node, then it could be coming from dom.generated.d.ts, which did delete a bunch of references recently.

[sandersn]

this is now typed because CancelToken has an @class tag.

Note that this, and the existing two errors, is a result of not tracking this property assignments through aliasing:

var token = this
executor(function (message) {
  if (token.reason) { return }
  token.reason = new Cancel(message)
})

If you switch to an arrow function and remove the aliasing, we infer this correctly:

executor((message) => {
  if (this.reason) { return }
  this.reason = new Cancel(message)
})

[sandersn]

I'm not sure what is going on here either -- the lib.dom.d.ts didn't change around HTMLElement, and only to add an index signature. debug itself hasn't changed either. And I don't think document.documentElement was previously any by mistake, because the previous type error was on document.documentElement.style.

[sandersn]

generated d.ts now has an alias type TimerHandler = string | Function. This, uh, happens a lot in places that don't handle timers. I don't think it should be a built-in alias.

[sandersn]

in wrapperLodash.js, function lodash is marked with @constructor, despite not referencing this. It is literally a wrapper for calling return new LodashWrapper along with a few other cases. It's not a constructor function, but a factory function.

[sandersn]

These two are a result of generated DOM changes too.

[sandersn]

This is one of the PRs at fault. microsoft/TypeScript-DOM-lib-generator#524

[weswigham]

I reran the user tests post-lib changes and #26156 has the diff. The changes look like the expected/acceptable ones to me - @sandersn wanna merge if you agree?

[sandersn]

I'll take a look.