Return undefined instead of empty string from .json() on empty responses

[sindresorhus]

Fixes #732

[sindresorhus]

I'm aware it could be just return, but maybe having undefined there explicitly makes it slightly more readable.

[sholladay]

Code LGTM but my opinion remains that we should return valid JSON if the method does not throw.

[sindresorhus]

but my opinion remains that we should return valid JSON if the method does not throw.

What exactly do you propose then?

• Keep it ''. That's not valid JSON.
• Go back to throwing again. Less user-friendly.

[sholladay]

My thinking was that an empty body is equivalent to an empty string, because HTTP is just text over the wire. And you can get an empty string back from the JSON parser.

JSON.parse('""') === '';
// => true

I take it back, though. I thought that JSON.parse('') was loose and also returned an empty string, but no. It throws, which I suppose is for the best. So we should treat them differently, too.

My other main reason for preferring an empty string over undefined was React's rendering behavior. I often parse JSON and then display it, e.g. for debugging. For a long time, rendering undefined would cause React to throw. But apparently they started allowing undefined in React 18. So that's moot now.

Let's do it. 👍

[biesbjerg]

Not sure you'll see this since it's merged, but widening to Promise<J | undefined> means that we have to guard against it at call sites which I wouldn't expect when explicitly passing in expected return type?

const response = http.get(`projects/${projectName}/build-number`).json<BuildNumberResponse>();

if (response !== undefined) { ... }

[sholladay]

@sindresorhus I've seen about 10 comments on this so far. Seems to be the most common issue people run into with 2.0.

[sindresorhus]

#854