This is the correct behavior - at runtime, .then(null) creates a new Promise with the original underlying value propagated out.

var a = Promise.resolve("hello world").then(null).then(x => console.log(x))

// prints 'hello world'

While you might prefer to never allow null | undefined to be passed into .then(), it's both allowed by the spec and permits patterns that are arguably useful (such as optionally-present handlers to transform values).

I don’t think that’s the issue that’s being demonstrated here. Minimal repro:

const pNumber = Promise.resolve(0);
const pString: Promise<string> = pNumber.then(); // No error

The issue is that without a callback argument to then, the only inference source for its type parameter is the contextual type (in my type annotation here, in the function return types in the repro from @blackdyedsheep).

Whoops, I misread. Apologies.

The easy fix I thought of was to add an overload for optional undefined/null, but I’m not sure how well that stacks up against the easiest fix, “just don’t write .then(null).” Is there a real use case for writing code like that?

Yes, there is a real use case, that's how I came across this behaviour.

Quoting @DanielRosenwasser :

optionally-present handlers to transform values

ie this code should infer Promise<0 | string> but infers Promise<string>

function maybeTransform(fn?: (v: number) => string) {
	return Promise.resolve(0).then(fn);
}

and this code should not compile

function maybeTransform(fn?: (v: number) => string): Promise<string> {
	return Promise.resolve(0).then(fn);
}

Basically it should behave the same way as

function maybeTransform(fn?: (v: number) => string) {
	return fn ? fn(0) : 0;
}

I think this can be solved with overloads, but because overload resolution doesn’t happen during inference, I think it’s going to be incredibly breaky. #58678 is up to experiment, but I don’t think it will be viable.

Probably nobody calls Promise.resolve(0).then<string>() either except when they do. I'd say it's the same basic issue whether the type is inferred contextually from an unexpected place or the type argument is specified manually: generic defaults don't exactly match the use case, which looks like #56315. The use case in question is something like "when the optional thing is omitted by the caller, it is effectively supplied by the implementer". Generic defaults sort of do this, except when they don't.

I think this can be solved with overloads, but because overload resolution doesn’t happen during inference, I think it’s going to be incredibly breaky. #58678 is up to experiment, but I don’t think it will be viable.

interface Promise<T> {
  // specific overloads
  then<TResult1, TResult2>(
    onfulfilled: (value: T) => TResult1 | PromiseLike<TResult1>,
    onrejected: (reason: any) => TResult2 | PromiseLike<TResult2>
  ): Promise<TResult1 | TResult2>;
  then<TResult>(onfulfilled: null | undefined, onrejected: (reason: any) => TResult | PromiseLike<TResult>): Promise<T | TResult>;
  then<TResult>(onfulfilled: (value: T) => TResult | PromiseLike<TResult>, onrejected?: null | undefined): Promise<TResult>;
  then(onfulfilled?: null | undefined, onrejected?: null | undefined): Promise<T>;

  // catch all overload
  then<TResult1 = T, TResult2 = never>(
    onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | undefined | null,
    onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
  ): Promise<TResult1 | TResult2>;
}

This is fairly accurate and works as expected, for the most part. The specific overloads are all mutually exclusive with each other and are designed to avoid introducing a type variable in the return type of then() that might not be otherwise witnessed when a callback is null, undefined, or not supplied. The catch-all overload allows for various combinations of the specific overloads in cases where you might pass a variable of type (() => T) | null | undefined as it would not match any of the specific overloads despite being perfectly legal.

Unfortunately, it causes #36307 to regress, so it's still not completely reliable.

Ideally, we could solve this during inference by relying on some heuristic related to the fact that TResult1 has a default and no other inferences aside from the return type. Unfortunately, I haven't yet found a reliable heuristic that doesn't break some other expectation somewhere else.