fix(#2767): Fix serilization issues of bigint in json body

[helloanoop]

Fixes: #2767

[github-actions]

Test Results

  1 files  ±0   59 suites  +1   21s ⏱️ -1s
 84 tests ±0   84 ✅ ±0  0 💤 ±0  0 ❌ ±0 
131 runs  +1  131 ✅ +1  0 💤 ±0  0 ❌ ±0 

Results for commit 00e9845. ± Comparison against base commit b4fd350.

♻️ This comment has been updated with latest results.

[helloanoop]

The serialization is now lossless. Just need to fix the deserialization next by providing a toggle at collection level setting to disable parsing response as json (when the content type is application/json)

[Its-treason]

This causes a horizontal overflow, if the text is too long

[helloanoop]

Nice catch. Fixed

[Its-treason]

This should probably also check if the Object is a "plain" object with data.constructor === Object (or something else). Setting a FormData object as the body does not work now, but worked previously.

[helloanoop]

This makes sense. Will have this updated.

[helloanoop]

So I have updated the logic to also check if content type is json (based on headers).
This should cover the use case of people setting body as FormData object.

If someone has set the Content-Type as json in the header (or it gets auto added if they have chosen JSON as body in UI), and then they try to pass a non-plain object while invoking setBody() - they are essentially shooting themselves in the foot and we don't need to gracefully handle that.

The reason why are supporting the raw option is to support use cases where people want to still have the content type as json, but want to pass the json strings themselves instead of passing the json object

@Its-treason lmk if you differ or have further suggestions

setBody(data, options = {}) {
    if (options.raw) {
      this.req.data = data;
      this.body = data;
      return;
    }

    const isJson = hasJSONContentType(this.req.headers);
    if (isJson && this.__isObject(data)) {
      this.body = data;
      this.req.data = this.__safeStringifyJSON(data);
      return;
    }

    this.req.data = data;
    this.body = data;
  }

[Its-treason]

What about req.body that is set inside the constructor? I think this should also be JSON parsed like req.getBody

[helloanoop]

💯 good catch (this could have resulted in breakages for folks who were accessing req.body in scripts)

Have updated the code with a comment

constructor(req) {
    // existing code

    /**
     * We automatically parse the JSON body if the content type is JSON
     * This is to make it easier for the user to access the body directly
     * 
     * It must be noted that the request data is always a string and is what gets sent over the network
     * If the user wants to access the raw data, they can use getBody({raw: true}) method 
     */
    const isJson = hasJSONContentType(this.req.headers);
    if (isJson) {
      this.body = this.__safeParseJSON(req.data);
    }
  }

[helloanoop]

@Its-treason I have addressed all your comments and have also made some updates. Let me know if you have further comments

@lohxt1 will take over from here and add further changes on this PR to add a toggle in bruno.json to support disabling the behaviour of bruno automatically parsing response as json (if the response is a valid json). This is aimed at solving the problem around the response text losing its fidelity during the JSON.parse operation

bruno.json

{
    parseResponseJson: true
}

[helloanoop]

Another option that I am thinking to solve problems for folks who don’t want us to to automatically parse response as json (where the response loses fidelity in some cases) is to provide an api that can disable this.

req.disableParsingResponseJson()

They can use this then at request level scripting, or apply it to folder level or collection level scripts as they see fit.

We can consider providing a UI toggle much later if there is demand for it.

[helloanoop]

The PR is GTG from my side.

Folks who don’t want us to to automatically parse response as json (where the response text loses fidelity in some cases) can use the new api method req.disableParsingResponseJson()

They can use this at request level scripting, or apply it to folder level or collection level scripts as they see fit.

@Its-treason @jwetzell let me know if you have any further comments. I plan to have this merged tomorrow.

[MeskaKeyne]

hello, fix seems not working in 1.27.0

eg
{
"id": 1.0000000000000493e+21,
"dateFrom": "2019-08-08",
}