Is the startWith operator in RXJS really deprecated?

I also got a deprecated message when I was trying to startWith(undefined) The reason is it's defaulting to export declare function startWith<T>(scheduler: SchedulerLike): MonoTypeOperatorFunction<T>; the deprecated API

The fix is specifying the return type D(of the undefined): export declare function startWith<T, D>(v1: D): OperatorFunction<T, T | D>;

For example let's say I have Interface MyType1 and my observable maps it to myType2: startWith<MyType1, MyType1>(undefined)

No, it is not.

Currently there is only one active signature: startWith(...values)

Apart from this signature, it has several overloads which accept scheduler: SchedulerLike as the latest parameter: startWith(...values, scheduler) and this functionality has been deprecated.

If you don't use scheduler with startWith you are fine.

If you do, then you need rewrite your code using scheduled function like they suggest in the comment beside depreciation annotation: scheduled([[a, b, c], source], scheduler).pipe(concatAll()).

---

Highly likely, you are using startWith(null) or startWith(undefined), they are not deprecated despite the notice, but IDE detects a wrong function signature, which is deprecated, and shows the warning.

Or, you are using formControl.valueChanges which emits any type, or any other observable stream with any. Because any matches the SchedulerLike, you see the notice.

Therefore, try to avoid any via adding filter((v): v is number => typeof === 'number') or any other possible way.

For ones who see the deprecated warning in VSCode when you are using startWith(null), just replace it with startWith(<string>null) in order to resolve the warning message.

More information is here.

One way to avoid the deprecation notice is by typecasting whatever you're passing into startWith. For example startwith(x as boolean) in the OP's example.

This way, you're reassuring your IDE that you're not using a deprecated signature.