Support alternative JSON library

Is your feature request related to a problem? Please describe.

This is both a feature request and a bug report. Consider the following :

import { rest } from 'msw';
import { setupServer } from 'msw/node';
import axios from 'axios';
import JSONbig from 'json-bigint';

// This is required by Jest to work properly
BigInt.prototype.toJSON = function() { return this.toString(); };

const mockBaseUrl = "http://localhost/services/acme/api";

const customer = {
  "username": "Dude",
  "balance": BigInt(1597928668063727616) // yes, the Dude is rich
};

const server = setupServer(
  rest.get(`${mockBaseUrl}/customers/me`, (req, res, ctx) => {
    return res(
      ctx.status(200),
      ctx.json(customer),
    )
  }),
)

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

const apiAxios = axios.create({
  transformResponse: [data => data ? JSONbig.parse(data) : data],
});

describe("Mocks", () => {

  it("should mock a basic GET call", () => {
    const url = `${mockBaseUrl}/customers/me/`;

    return expect(apiAxios.get(url).then(r => r.data)).resolves.toEqual(customer);
  });
});

This test result in the following error :

Error: expect(received).resolves.toEqual(expected) // deep equality

- Expected
+ Received

  Object {
-   "balance": 1597928668063727616n,
+   "balance": "1597928668063727616",
    "username": "Dude",
  }

Describe the solution you’d like

One simple solution would be to be able to set the JSON library to use while transforming the response, as it looks like you internally transform to json. In my case the common library to handle BigInt is json-bigint.

Describe alternatives you’ve considered I’m still looking into creating my own response transformer to handle BigInt but there is no documentation about it so it’s quite time consuming.

[marcosvega91]

yes of course

[kettanaito]

I think that the default transformers should reside on the res composition function. This should be clear, as the default res function stringifies responses using JSON.stringify, if you wish to have a custom stringification, create a custom composition function. I think this is the right message to give to the users, as they shouldn’t think of the res functions as something magical. It’s a plain function you should be able to compose into another function, or replace entirely.

I like your approach of creating a custom response function via createResponseComposition. We should expose this function publicly and allow users to customize built-in transformers that way. As of whether those transformers should be on the MockedResponse, or accepted by the createResponseComposition as an argument—I’m not sure.

• Set on the response.
  • Pros: accessible from within any response transformer, including custom ones.
  • Cons: would most likely contain the same set of built-in transformers on each response object.
• Set on the createResponseComposition
  • Pros: conceptually isolates built-in transformers.
  • Cons: slightly unintuitive that you give certain transformers as an argument to createResponseComposition, while other transformers straight to the created res function.

Worker and server instances represent interception layer as a whole, they shouldn’t care about how response is stringified. On the implementation level it would be a huge argument drilling chain to get options.transformers down to each res function, which is a good sign it doesn’t belong to StartOptions.