MSW is not intercepting in development in nextjs and graphql api

[themashcodee]

Hey,
MSW is not intercepting in the development mode in nextjs. I am using the Strapi Graphql API. Everything is working in unit tests but not in the development mode. Below is the minimal reproduction repo you have to run it on only localhost:3000 for testing the API. I would massively appreciate any help. Thanks

https://github.com/themashcodee/msw-nextjs-graphql-testing

[kettanaito]

Hey, @themashcodee. Thanks for reporting this.

So the query is not intercepted because by the time it happens the worker is not done registering. I've spotted this by debugging the activeClientsIds in the mockServiceWorker.js file:

msw/src/mockServiceWorker.js

Lines 261 to 266 in 527add2

	// Bypass all requests when there are no active clients.
	// Prevents the self-unregistered worked from handling requests
	// after it's been deleted (still remains active until the next reload).
	if (activeClientIds.size === 0) {
	return
	}

As the condition above states, if there are no clients (tabs where the worker is ready), bypass the request. That's precisely what's happening.

The race condition between the worker registration and whichever requests an app may perform is still something we're working on solving. Currently, there's the request deferring logic that should capture and replay any requests happening in that race condition timeframe. That's clearly not what's happening in your case. At first, I suspected the custom fetch to be the reason for that but even when using the native fetch the deferring of requests does not happen. If you have any suggestions about how we could approach this I'd be thankful.

For now, what I did is deferred the app's mounting (as described in the Deferred mounting page) so that your app mounts after the worker is ready:

import 'styles/globals.css'
import type { AppProps } from 'next/app'
import { Apollo } from 'services/apollo-client'
import { useEffect, useState } from 'react'

const { API_MOCKING } = process.env

const MyApp = ({ Component, pageProps: pageProps }: AppProps) => {
  const [shouldRender, setShouldRender] = useState(!API_MOCKING)

  useEffect(() => {
    async function initMocks() {
      const { setupMocks } = await import('mocks')
      await setupMocks()
      setShouldRender(true)
    }

    if (API_MOCKING) {
      initMocks()
    }
  }, [])

  if (!shouldRender) {
    return null
  }

  return (
    <>
      <Apollo>
        <Component {...pageProps} />
      </Apollo>
    </>
  )
}

export default MyApp

I'd much prefer for this to be handled by the library but for the lack of such handling at the moment this is what I'd recommend you try.

[kettanaito]

@alstn2468, I don't have any insight as to how the Suspense API can affect that, if it all. Give it a try by yourself.

[adeleke5140]

I am currently on next 13.2.4 and msw ^1.2.1 and for me, the problem seem to be that sometimes it works and other times it doesn't.

Right now, in my next app, the request are made before the msw which leads to errors.

[alex-way]

Just as a small amendment, the function definition and then subsequent immediate call is unrequired, you can simplify it slightly to the below:

import { useEffect, useState } from "react";
import type { AppProps } from 'next/app'

export default function App({ Component, pageProps }: AppProps) {
  const mockingEnabled = !!process.env.NEXT_PUBLIC_API_MOCKING;
  const [shouldRender, setShouldRender] = useState(!mockingEnabled);

  useEffect(() => {
    if (mockingEnabled) {
      import("../mocks").then(async ({ initMocks }) => {
        await initMocks();
        setShouldRender(true);
      });
    }
  }, []);

  return shouldRender ? <Component {...pageProps} /> : <>Loading mocks...</>;
}

[garyfagan]

@alex-way Thanks! Works perfectly!

[SinanBaymammadli]

Adding initMocks function here, it took me some to realize that we need to await worker.start();

export async function initMocks() {
  if (typeof window === "undefined") {
    const { server } = await import("./server");
    server.listen();
  } else {
    const { worker } = await import("./browser");
    await worker.start();
  }
}

[allangrds]

I'm using "next": "13.2.1" and "msw": "^1.0.1", and the problem remains event following the code of next github

[kettanaito]

Are you certain you're awaiting the worker registration promise? That's very likely the case.

We also don't have an official integration with Next 13. That version is still experimental and they seemed to have moved away from some concepts like _app, making it harder to execute an async code once before the app runs. If you figure it out, post it here or open a PR to the MSW example in the Next.js repo. I'd be thankful.

[ironforward]

probably not very useful information, but i'm using "next": "^13.2.3" and "msw": "^1.1.0" -- and i can at least confirm that using the old pages/ directory has msw still intercepting properly

[kettanaito]

Then it has to do with the new app directory structure of Next. There isn't yet an official recommendation we'd give on how to correctly integrate MSW into the new directory structure in Next. I simply haven't looked into new Next yet. If you're working on it actively, could you research where it'd be the best place to put the worker promise? What we need is to defer the entire app until that promise resolves. Previously, we achieve that through an internal state in _app that didn't render anything until worker.start() resolves (state update -> render the app). That doesn't seem to be the case anymore.

[kettanaito]

If we can nail MSW integration with the new Next directory, it'd be a huge win for the entire community!

[allangrds]

To make it work, I followed the approach with the shouldRender state variable

[SalahAdDin]

Still a big issue in 14 version!

[seckinyasar]

still a problem for "next": "16.1.0", doesn't works with hmr.

[kettanaito]

Update

For anyone still experiencing this in modern versions of Next.js, the framework doesn't work well with MSW as it lacks proper entrypoints to be integrated with. There is nothing we can do on MSW's side and this rests entirely on the Next.js team. I trust they do their best and address issues to their best availability. It doesn't help sharing that you're still experiencing the issue.

It might help bringing this up to the Next.js team's attention to show that there are users affected by this. If this ever gets solved, the mswjs/examples#101 example will be updated. Please follow any progress here.