Update JSON.stringify

[nmn]

To ban the the input value 'undefined' passing in undefined returns undefined. Therefore making the return type incorrect.
We could also add an overload for a type that takes undefined and returns undefined but that's redundant anyway.

NOTE: functions aren't allowed to be inputs either, but I don't know how to not allow functions but allow all other functions in Typescript.

Fixes #

[typescript-bot]

It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src'. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src'.

[nmn]

Looked at some of the failing tests and they are legitimate problems that need to be fixed. JSON.stringify should not be called with undefined. I'll need help fixing those issues, or I can just close this PR and someone else can pick this up.

[zackschuster]

nit: JSON.stringify(Symbol.for('foo')) === undefined, so symbol should be dropped

[chyzwar]

problem is return type from stringify not allowed value types. I think it should be undefined | string instead. This can be addressed by adding specific overloads. Please correct me if I am wrong.

[zackschuster]

string | undefined with --strictNullChecks would force you make an existential check at runtime, even when it's statically provable what the return type would be

[chyzwar]

but not when you have overloads.

stringify(value: Object | string | number | boolean  | null, replacer?: (this: any, key: string, value: any) => any, space?: string | number): string;

stringify(value: undefined | Function | symbol, replacer?: (this: any, key: string, value: any) => any, space?: string | number): undefined;

[zackschuster]

i misunderstood; based on the type signature you wrote i thought you were advocating for a single api. my apologies!

you are correct, an overloaded api would be strictly better. i checked your definitions against MDN and they look correct too.

thank you :)

[sindresorhus]

Shouldn't it be object instead of Object?

And it would useful to move this into a JSONStringifyable type so it can be reused.

[zackschuster]

you're correct; object narrows out symbol where Object does not:

declare class Foo {
	foo(o: object): boolean;
	foo(o: symbol | Function): string;
}
new Foo().foo(Symbol.for('')); // string

declare class Bar {
	bar(o: Object): boolean;
	bar(o: symbol | Function): string;
}
new Bar().bar(Symbol.for('')); // boolean

unfortunately, i found a different issue:

new Foo().foo(() => { }); // boolean, should be string
new Bar().bar(() => { }); // boolean, should be string

this would be most readily resolved by moving the overload with Function above the "happy path" overload. unsure if that's the right decision or if there's an alternative i'm missing.

[zackschuster]

see above

[RyanCavanaugh]

What issue is tracking this change?

[zackschuster]

@RyanCavanaugh #18879, though i'm pretty sure OP came from this tweet

[nmn]

Haven't forgotten, I'll make the change to remove symbol from the list and try and fix the failing tests.

[RyanCavanaugh]

Closing due to long-term CI failure

See also comments in #29962 (comment) if anyone wants to open a fresh PR