msw: Unable to intercept requests sent during pre-rendering in Next.js
Prerequisites
- I confirm my issue is not in the opened issues
- I confirm the Frequently Asked Questions didn’t contain the answer to my issue
Environment check
- I’m using the latest
msw
version - I’m using Node.js version 14 or higher
Node.js version
v18.3.0
Reproduction repository
https://github.com/ajfAfg/msw-operation-research
Reproduction steps
- Run the following commands
git clone https://github.com/ajfAfg/msw-operation-research.git
cd msw-operation-research/nextjs-rest
npm install
npm run dev
Current behavior
In src/pages/index.tsx
, getServerSideProps
fetches data and outputs the received data to the console. Currently, the output is as follows.
server: {"answer":"yes","forced":false,"image":"https://yesno.wtf/assets/yes/14-b57c6dc03aa15a4b18f53eb50d6197ee.gif"}
The data being fetched here is as follows.
$ curl https://yesno.wtf/api
{"answer":"yes","forced":false,"image":"https://yesno.wtf/assets/yes/11-a23cbde4ae018bbda812d2d8b2b8fc6c.gif"}
Expected behavior
The expected output is as follows, since the request is intercepted by the definition in src/mocks/handlers.ts
.
server: {"foo":"bar"}
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 17 (3 by maintainers)
Anyone got this working in Next13 ?
@kettanaito The issue with NextJS and MSW being enabled to intercept client side requests still exists.
Using node:
v16.18.1
npm:8.19.2
I’ve managed to fix the issue. But it involved changing a few things in the Next.JS setup. Had to enable webpack experiments of topLevelAwait along with changing TypeScript
tsconfig.json
target
fromES5
toESNext
So I could change
_app.tsx
from usingto
You can see all the changes in this commit https://github.com/andykenward/next-with-msw/commit/91d9bbda12baff864913dc9eb95e7d921d75fb27
To reproduce the client side error before the above changes, checkout commit https://github.com/andykenward/next-with-msw/commit/3d00db8f66b12e5496881b18bbd3b903a479f0df
You should get this error on the server from the client side fetch happening in a
useEffect
I’ve started to also look into using the new Next.JS app directory changes they are currently working on. But haven’t managed to get it working yet. https://github.com/andykenward/next-with-msw/tree/main/with-msw-app . Will probably hold off until msw native fetch support version is released.
I am seeing this error in NextJS 13 when using the
pages
directory. The MSW server is unable to intercept server-side requests reliably. You can reproduce this by running the official with-msw example. It will throw this error from the request ingetServerSideProps
:It also does not work if you upgrade the example to
msw@next
.In my own app, I see that server side requests are occasionally intercepted, but most times not.
I have also opened an issue in Next.js: https://github.com/vercel/next.js/issues/56608
@watch-janick The NextJs MSW example is using an exact version of msw
0.47.3
and doesn’t install the latest version. If you update it to the latest version0.49.0
it should work. I’ve fixed the example in this PR https://github.com/vercel/next.js/pull/43224@philwolstenholme I’ve not managed to get msw working using the
app
directory Next.js feature. I’ve found that layout components render after the page component, when usingnext dev
. So any data fetching in a page that needs msw already loaded would fail. But even moving any MSW logic to a page component didn’t help in getting MSW working.I have found that using any top level async, throws any error in
next-swc-loader
. Which my fix uses.This error only threw when i removed the if statement check.
I don’ t think you are able to change the compile output target at the moment when using the
app
directory in Next.js.A working example repo from the tweet author would be helpful.
I’ve found using
await import
instead ofrequire
was the only reliable & consistent way to have MSW loaded before fetch requests. Otherwise i was getting flaky tests etc.@andykenward thanks man!
We’ve just recently protected our API route and we didn’t put auth headers on the request that went out to that API so we got 2 nasty surprises:
Implementing your solution works for now!
@kettanaito I’ve not checked the “reproduction repository” https://github.com/ajfAfg/msw-operation-research in this issue. Will do that now and also try the latest msw
0.49.0
. But I wont use node 18.