• I added the following code to the template in order to support SSR with Next.js

if (typeof window === 'undefined') {
  const { setupServer } = require('msw/node');
  const server = setupServer(...handlers);
  server.listen();
} else {
  const worker = setupWorker(...handlers);
  worker.start();
}

• It's pretty much the same as the example from Next.js
• Updated the version of faker.js and regenerated mock.js in /example

faker removed default export from v7.0.0 It's a breaking change, so the way of importing faker (https://github.com/zoubingwu/msw-auto-mock/blob/master/src/template.ts#L14) should be changed to import { faker } from '@faker-js/faker';. Otherwise it can't work with faker v7.

I am very impressed with the library, very useful.

I had to implement it by adding a d.ts file in order to work in my repository. I think it would be a good addition to it.

I also think the library should be decoubled from MSW implementation, so it removes work for you and usage will not add unused code. With this addition in mind we could even have parameters to modify handlers individually to differents tests scenarios.

Thank you again and keep on the good work!

Due to the inner workings of MSW, handlers must be defined in a certain order to avoid ambiguous paths. See more here. In short handlers with path parameters must be listed after handlers with static paths otherwise they will match to wrong path. A way to solve it would be to sort the handlers array by path. Thank you for the lib!

Hi @zoubingwu, first of all thanks for this, it's a great tool and saves a lot of time!

There is one bit of the implementation that could simplify (in my opinion) the usage for a few people.

When using Webpack in a client side app (eg a React app generated with https://create-react-app.dev/), there are issues in importing modules supposed to run in a node environment.

Because of that, this bit causes a bit of issues:

export const startWorker = () => {
  if (typeof window === "undefined") {
    const { setupServer } = require("msw/node");
    const server = setupServer(...handlers);
    server.listen();
  } else {
    const worker = setupWorker(...handlers);
    worker.start();
  }
};

do you think it would make sense to add a flag like --browser to change that piece of code to smaller when set? For example:

export const startWorker = () => {
    const worker = setupWorker(...handlers);
    worker.start();
};

Hi there, thanks for this great package!

I am running @faker-js/[email protected] in my project, and I'm seeing a warning in my console for each time findName is called:

So I followed their advice, and here's my console after this PR:

Thanks again.

msw-auto-mock seems to have Problems with return values based on components/models with nested objects which have allOf instead of type. This is a standard open-api document and it's being generated by Swashbuckle See below the schema of the PaymentResultApiResponse and the result prop.

Open-API Doc Example below

"/v1/checkout/get-payment-status": {
      "post": {
        "tags": [
          "Checkout",
          "RequiresAuthentication",
          "RequiresKycTier-0"
        ],
        "operationId": "GetPaymentStatus",
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "allOf": [
                  {
                    "$ref": "#/components/schemas/GetPaymentStatusRequest"
                  }
                ]
              }
            }
          }
        },
        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/PaymentResultApiResponse"
                }
              }
            }
          },
          "429": {
            "description": "Too Many Requests"
          },
          "400": {
            "description": "Bad Request",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/ApiResponse"
                }
              }
            }
          }
        },
        "security": [
          { }
        ]
      }
    },

// ...
  "components": {
    "schemas": {
        "PaymentResultApiResponse": {
            "required": [
            "isSuccessful"
            ],
            "type": "object",
            "properties": {
            "result": {
                "allOf": [ <--- is not being generated
                {
                    "$ref": "#/components/schemas/PaymentResult"
                }
                ],
                "nullable": true
            },
            "timestamp": {
                "type": "integer",
                "format": "int64",
                "readOnly": true
            },
            "isSuccessful": {
                "type": "boolean"
            },
            "errorMessage": {
                "type": "string",
                "nullable": true
            },
            "errorCode": {
                "type": "integer",
                "format": "int32",
                "nullable": true
            },
            "requestId": {
                "type": "string",
                "nullable": true
            }
            },
            "additionalProperties": false
        },

Output:

 ctx.json({
          result: null,
          timestamp: faker.datatype.number(),
          isSuccessful: faker.datatype.boolean(),
          errorMessage: faker.lorem.slug(1),
          errorCode: faker.datatype.number(),
          requestId: faker.lorem.slug(1),
        }),

hey, I really like this idea and I have thought of something that could improve it:

I have a scenario where I also have to replicate functional business logic, so it would be nice if:

• mocked responses were not inlined in each handlers,
• mocked responses were exported so they could be mutate or used in @msw/data
• handlers were generated with createHandler function that could take a mocked response as a param