Undocumented breaking change

[lpinca]

What would you like to discuss?

There seems to be an undocumented breaking change in got@10 when the response body is empty and the responseType option is set to 'json'.

const got = require('got');
const { createServer } = require('http');

const server = createServer(function(request, response) {
  response.end();
});

server.listen(function() {
  const { port } = this.address();

  got(`http://localhost:${port}`, { responseType: 'json' })
    .then(function(response) {
      console.log(response.body);
    })
    .catch(console.error)
    .finally(function() {
      server.close();
    });
});

The promise is rejected with a got.ParseError.

In got@9.6.0 the same code with the json option set to true, returns a promise which is resolved and response.body is set to an empty string.

Is the breaking change intentional?

Checklist

• I have read the documentation.

[szmarczak]

An empty string is still valid JSON.

[szmarczak]

It has been mentioned in release notes:

[lpinca]

From the reply I think I was not clear or the report was not read carefully. My expectation is that no error is thrown when the response body is empty. got@10 throws.

[lpinca]

@szmarczak can you please reopen or clarify?

[lpinca]

An empty string is still valid JSON.

In the sense that now you try to JSON.parse() it? Even if you know that it will fail? It wasn't like this in got@9.

If the change is intended I'm fine with it but it should be documented and no, this

Don't throw on 204 No Content when parsing response (#925) 518f0f5

is not enough because the change affects all responses not only 204.

[szmarczak]

This is fixed in 071bf5e I'll also write a test for it.

[szmarczak]

This is tested here: d709fd7

[szmarczak]

Sorry for misunderstanding the issue. Indeed, this was a regression.