Keep startWith(null), don't set as deprecated. (why?)

[infacto]

myObservable
  .pipe(startWith(null), pairwise())
  .subscribe(([prev, curr]) => console.log(prev, curr))

The signature '(scheduler: SchedulerLike): MonoTypeOperatorFunction' of 'startWith' is deprecated. ts(6387)
deprecated — use scheduled and concatAll (e.g. scheduled([[a, b, c], source], scheduler).pipe(concatAll()))

This should not happen. The pipe startWith is very useful and poweful here. I would not set it as deprecated. The suggested solution with scheduled is confusing and cumbersome.

Related issue #4772 but I still don't understand the problem here. "Deprecated" means it will be removed soon. But why? Because it's too handy, easy or just good? ;) We should avoid deprecated stuff. Can anyone explain it please? Preferably with colorful hand puppets. ^^

[voliva]

What version are you using? The definition file of startWith on latest version is this one:

export declare function startWith<T>(value: null): OperatorFunction<T, T | null>;
export declare function startWith<T>(value: undefined): OperatorFunction<T, T | undefined>;
/** @deprecated The `scheduler` parameter will be removed in v8. Use `scheduled` and `concatAll`. Details: https://rxjs.dev/deprecations/scheduler-argument */
export declare function startWith<T, A extends readonly unknown[] = T[]>(...valuesAndScheduler: [...A, SchedulerLike]): OperatorFunction<T, T | ValueFromArray<A>>;
export declare function startWith<T, A extends readonly unknown[] = T[]>(...values: A): OperatorFunction<T, T | ValueFromArray<A>>;

The only overload that's marked as deprecated is the one that takes an scheduler as the last argument.

Can you provide a playground with this showing up? I set up one here https://codesandbox.io/s/sleepy-sea-0yjr3f?file=/src/index.ts:361-370 with both a snippet that uses a deprecated overload and another one that doesn't, and it seems to be working fine.

[infacto]

Thanks, I missed it. Yes I still use the v6.6 (Angular). This issue does not exist in v7.5 anymore. And I see the following comment:

Devs are more likely to pass null or undefined than they are a scheduler
without accompanying values. To make things easier for (naughty) devs who
use the strictNullChecks: false TypeScript compiler option, these
overloads with explicit null and undefined values are included.

As I understand correctly. This only happen (in v6) in projects without strict mode? Yes it seems so. I tested it...

With strict: true (tsconfig.json) it chooses the type:

export declare function startWith<T, D>(v1: D): OperatorFunction<T, T | D>;

without strict mode it chooses the type:

/** @deprecated use {@link scheduled} and {@link concatAll} (e.g. `scheduled([[a, b, c], source], scheduler).pipe(concatAll())`) */
export declare function startWith<T>(scheduler: SchedulerLike): MonoTypeOperatorFunction<T>;

(d.ts from v6.6)

That is interesting... 🤔 I didn't quite understand, but ok.

In v7 there are two delcarations for that cases:

export function startWith<T>(value: null): OperatorFunction<T, T | null>;
export function startWith<T>(value: undefined): OperatorFunction<T, T | undefined>;

In general I always working with strict mode enabled. I would not say, that I'm a "naughty" dev. ^^ It's just not possible sometimes when you're working on large old projects of companies. But I already found a tool to enable strict mode per file to update granularly. Anyway... It was just confusing. But I think this topic is now "deprecated". 🙂 Sorry, I usually test with the latest version first before reporting anything.