Intercept external URL fetch via ServiceWorker running on localhost

Question

I have a set of integration tests which run in Karma. Unfortunately, they call out to an external, production API endpoint. I do not want integration tests to call out and am exploring my options.

I am wondering if service workers are a viable solution. My assumption is that they do not work because https://github.com/w3c/ServiceWorker/issues/1188 makes it clear that cross-origin fetch is not supported and localhost is not the same origin as a production API endpoint.

For clarity, here is some code I am running:

  try {
    const { scope, installing, waiting, active } = await navigator.serviceWorker.register('./base/htdocs/test/imageMock.sw.js');
    console.log('ServiceWorker registration successful with scope: ', scope, installing, waiting, active);


    (installing || waiting || active).addEventListener('statechange', (e) => {
      console.log('state', e.target.state);
    });
  } catch (error) {
    console.error('ServiceWorker registration failed: ', error);
  }

and the service worker

// imageMock.sw.js

if (typeof self.skipWaiting === 'function') {
  console.log('self.skipWaiting() is supported.');
  self.addEventListener('install', (e) => {
    // See https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-global-scope-skipwaiting
    e.waitUntil(self.skipWaiting());
  });
} else {
  console.log('self.skipWaiting() is not supported.');
}

if (self.clients && (typeof self.clients.claim === 'function')) {
  console.log('self.clients.claim() is supported.');
  self.addEventListener('activate', (e) => {
    // See https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#clients-claim-method
    e.waitUntil(self.clients.claim());
  });
} else {
  console.log('self.clients.claim() is not supported.');
}

self.addEventListener('fetch', (event) => {
  console.log('fetching resource', event);
  if (/\.jpg$/.test(event.request.url)) {
    const response = new Response('<p>This is a response that comes from your service worker!</p>', {
      headers: { 'Content-Type': 'text/html' },
    });

    event.respondWith(response);
  }
});

and when this code is ran I see in the console

ServiceWorker registration successful with scope:  http://localhost:9876/base/htdocs/test/ null null ServiceWorker

and then requests to https://<productionServer>.com/image.php are not intercepted by the fetch handler.

Is it correct that there is no way to intercept in this scenario?

Answer 1

You can use a service worker to intercept requests made by a browser as part of a test suite. As long a service worker is in control of a web page, it can intercept cross-origin requests and generate any response you'd like.

(The issue you link to about "foreign fetch" is something different; think of it as the remote production server deploying its own service worker. This was abandoned.)

"Stop mocking fetch" is a comprehensive article covering how to use the msw service worker library within the context of a test suite.

I can't say off the top of my head exactly why your current setup isn't working, but from past experience, I can say that the most important thing to remember when doing this is that you need to delay making any requests from a client test page until the page itself is being controlled by an active service worker. Otherwise, there's a race condition in which you might end up firing off a request that needs to trigger a fetch handler, but won't if the service worker isn't yet in control.

You can wait for this to happen with logic like:

const controlledPromise = new Promise((resolve) => {
  // Resolve right away if this page is already controlled.
  if (navigator.serviceWorker.controller) {
    resolve();
  } else {
    navigator.serviceWorker.addEventListener('controllerchange', () => {
      resolve();
    });
  }
});

await controlledPromise;
// At this point, the page will be controlled by a service worker.
// You can start making requests at this point.

Note that for this use case, await navigator.serviceWorker.ready will not give you the behavior you need, as there can be a gap in time between when the navigator.serviceWorker.ready promise resolves and when the newly activated service worker takes control of the current page. You don't want that gap of time to lead to flaky tests.