Fix types for catchError

[leggechr]

Description:
The cast was removed in #5572 but it is needed in Google for this to compile.

[cartant]

@leggechr I'd kinda like to figure out why the problem is effected. What version of TS is used for the compilation? And how is the operator used? Does it differ from any of the uses in the dtslint tests?

[benlesh]

Yeah, I'm very curious as to why this wouldn't compile.

[leggechr]

So I actually think everywhere that this new lift operator is used the types are broken in Google for corresponding operators. It's been a while since I tried to fix these. I'm just trying to find the offending examples. Will update here once I've found them again.

[leggechr]

Okay the error that is thrown in google is with the actual catchError operator itself:

.../src/internal/operators/catchError.ts:130:5 - error TS2322: Type 'Observable<unknown>' is not assignable to type 'Observable<T>'.
  Type 'unknown' is not assignable to type 'T'.
    'unknown' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint '{}'.

130     operator.caught = caught;
        ~~~~~~~~~~~~~~~
.../src/internal/operators/catchError.ts:131:5 - error TS2322: Type 'Observable<unknown>' is not assignable to type 'Observable<T | ObservedValueOf<O>>'.
  Type 'unknown' is not assignable to type 'T | ObservedValueOf<O>'.
    Type 'unknown' is not assignable to type 'ObservedValueOf<O>'.

131     return caught;
        ~~~~~~~~~~~~~~

The version of typescript is 3.8.2.

[cartant]

It seems that, in this codebase, there is an any inference made in const operator = new CatchOperator(selector); but you are seeing unknown inferred instead. We are using a later TypeScript version: 3.9.2, so this is possibly version-related behaviour.

I'd look into this further, but it's likely that the change in this PR isn't needed, as Ben has refactored catchError - see #5627

Could you try the current master, @leggechr ?

[benlesh]

Okay... so I've run into this a couple of times, and it might be because we allow AsyncIterator as an ObservableInput now. That means that if tsconfig isn't set up with a target of esnext it will not be able to figure out what type things are, because AsyncIterator doesn't exist, and you get Observable<unknown> from ObservableValueOf<T>.

[cartant]

FWIW, es2018 should be sufficient, as AsyncIterator interface is in node_modules\typescript\lib\lib.es2018.asynciterable.d.ts. I think it's reasonable to impose a minimum lib for v7. The lib is just the types, after all.

[benlesh]

Related to #5708

[cartant]

Pretty sure this is closed by #5807