opened
weswigham
username_0
This does a few things:
* Increase user test timeout to 10m because npm can be slow (especially when not installing from a cache), and can cause tests time timeout on the much shorter (40s) timeout we were using 
* Remove parse5 because they [removed their own types](https://github.com/inikulin/parse5/issues/235)
  - We should probably talk to them, since they just broke all their TS consumers
* Accept updated class member error message for rxjs
* Accept current chrome baseline for reference and pin chrome-devtools-frontend version to today's version, so we can work from it while doing JS improvements while knowing that the underlying project isn't changing
External test runner updates
issue
created
sandersn
username_1
Sorry I didn't see this earlier. Looks like sift is broken by #17912. I'll go check it out.
comment
created
weswigham
username_0
I think the sift errors are legitimate errors in their .d.ts. at least that's the conclusion we came to in Friday.
comment
created
sandersn
username_1
Maybe. Here is a clearer repro:

```ts
function f<T extends any, P extends keyof T>(tp: T[P], aa: any[]) {
    aa = tp
}
```

The question is whether the constraint of `T[P]` is `any` when `T extends any`. I would say yes. Right now the answer is no.
comment
created
sandersn
username_1
After some investigation with @mhegazy, the picture is much muddier.

1. There is some precedent for *not* making `T extends any` equivalent to `any`. `Partial<any>` is not `any` but `{ [s: string]: any }`.
2. sift.js did not intend to constrain `T extends any`. They found it as a convenient workaround (that partially destroys their intended semantics). I don't think anybody says `T extends any` intentionally, in fact.
3. sift.js actually wants everybody's favourite infinite type that escaped from Lisp: `type Tree<T> = T | Array<Tree<T>>` (where T is not Array). This isn't really possible in Typescript until conditional types happen, and I'm not sure it's possible then.
4. @username_0 noticed that `T extends any === any` might interact badly with conditional types as currently implemented, so it's safer to leave this change until after those are done.

It's an easy change to make, but until there's more demand, I don't think this change is worthwhile.
comment