valendres / playwright-msw

A Mock Service Worker API for Playwright
MIT License
168 stars 24 forks source link

2 MSW Handlers. Unable To Override Default Active App Handler To Use Specific Set Of Handlers for Playwright? #101

Open Sayvai opened 2 months ago

Sayvai commented 2 months ago

So I am working on a private organisational repo, whereby I have a dev environment setup with MSW configured and working correctly, which can also be used in a live production environment to mock API calls for provisional demo purposes (e.g. browserHandlers.ts).

// client/src/main.tsx - original main app source code - starting the app with the default original MSW service worker at app level

async function enableMocking() {
  const { worker } = await import("./mocks/browser"); // šŸ‘ˆ handlers refer to `browserHandlers.ts`
  return worker.start();
}

...

enableMocking().then(() => {
  ReactDOM.createRoot(document.getElementById("root")!).render(
    <React.StrictMode>
      // Rest of React component code ...
    </React.StrictMode>
  );
});

In addition, I am also in the middle of integrating Playwright into the private repo, and would therefore want to use a different set of handlers (not the original initial browser mock handlers browserHandlers.ts), but instead use a new set of handlers I have defined in a separate directory (e.g. playwrightHandlers.ts), with the intention of the Playwright server using the new set of handlers (instead of the browserHandlers.ts).

// client/e2e/fixtures/test.ts - Playwright custom fixtures script configurations

const test = base.extend<ExtendedTestOptions>({
  // Add custom fixtures here
  worker: [
    async ({ page }, use) => {
      // šŸ‘‡ handlers refer to `playwrightHandlers.ts`, **but**, when the Playwright server is running, it's using `browserHandlers.ts`... (šŸ‘†)
      const server = await createWorker(page, handlers);
      // Test has not started to execute...
      await use(server);
      // Test has finished executing...
      // [insert any cleanup actions here]
    },
    { scope: "test", auto: true },
  ],
  http,
});

However, even after following the playwright-msw documentation, whereby the Playwright server is running, and is just re-using the already-running dev server, the handler for the browser is picked and used instead of the Playwright handlers (playwrightHandlers.ts).

I was hoping / expecting the Playwright handlers playwrightHandlers by the time the Playwright server had started, and thereby expected browserHandlers.ts to be ignored.

To verify that browserHandlers.ts is unexpectedly used, i manually commented out the call to worker.start() from within the main app source code to effectively temporarily disable browser handlers, and then restarted the Playwright server, whereby the handlers defined in playwrightHandlers.ts is now picked up and used. However, I would not want to fiddle / touch / update the main app source code just to ensure Playwright is mocking with the correct handler, as that could get messy, hacky, and harder to maintain.

Is there a way to manage this, so that whenever i start up the Playwright server alongside the already running dev server which at first itself is already actively running the core msw worker with browserHandlers.ts for mocking the app (irrespective of Playwright), to only use the playwrightHandlers.ts handlers when the Playwright server starts? Or am i missing additional configuration step(s)? šŸ¤”


Reproduction Steps - Expected vs Actual:
  1. Run app server locally in dev mode (MSW mock service runs with default browser handler)
  2. Run Playwright server locally (MSW should start another MSW mock service via playwright-msw library, and overriding default app browser handlers)

Actual -> Playwright server picks up MSW handlers from default browser handlers.

Expected -> Playwright server overrides and uses custom set of Playwright MSW handlers instead.


Dependency Versions:

What I have tried:

Aside from raising this issue #101, I have tried to use various scripted workarounds from further research on the internet, such as:


Alternative Considerations / Workarounds / Approaches