Support existing service worker?

[crutch12]

In the same time we are allowed to have only one service worker for one scope.

How could I connect msw to existing service worker?

If I use Workbox InjectManifest Plugin, for example, I already have sw.js file with my own settings
https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin

So I just need to "inject" eventListeners registrations from msw in my sw.js

But, as I can see, msw registers new service worker by itself.

Is there any way to start created msw worker without new service worker registering?

For example:

// sw.js
import { setupWorker, rest } from 'msw'

const worker = setupWorker(
  rest.post('/login', (req, res, ctx) => {
    const { username } = req.body
    return res(
      ctx.json({
        username,
        firstName: 'John'
      })
    )
  }),
)
// We are already in service worker
worker.startWithoutRegistration()

---

UPD:

I found out we have such cli:
$ npx msw init public/ --save

Which generates .js from this file:
https://github.com/mswjs/msw/blob/main/src/mockServiceWorker.js

So I can just generate this file and import it from my main sw.js

But

These event listeners may conflict with my main service worker

self.addEventListener('install', ...) // installHandler
self.addEventListener('activate', ...) // activateHandler
self.addEventListener('message', ...) // messageHandler
self.addEventListener('fetch', ...) // fetchHandler

Especially fetchHandler

Maybe we could export installHandler, activateHandler, messageHandler, fetchHandler functions' logic, so we could use it in another service worker?

[kettanaito]

Hey, @crutch12.

Combining MSW with another service worker is the same as combining two any workers. I highly recommend using the importScript function globally available in the worker's scope. It allows importing one service worker file within another.

Here's an example of how you can combine your own service worker with the MSW's one:

// public/custom.sw.js
importScript('./mockServiceWorker')

This example implies you've got the ./public/mockServiceWorker.js file generated via npx msw init CLI.

By using importScript, the browser automatically imports and executes the referenced worker. This includes registering event listeners like fetch and message, so you don't have to manually manage those. Pay attention to the order of execution to decide where to import the worker.

Precaution notice

That being said, keep in mind that MSW is a development tool primarily. You may use it in production for demoing and educational purposes but those are rather corner cases. You are unlikely to use your production workers during development so review carefully if combining workers is really what you need.

[crutch12]

Hi, @kettanaito

Thx for your answer!

I understand that I can import this script, but I don't get that -- how should I start msw worker?
Will this work with my custom.sw.js?

worker.start({
  serviceWorker: {
    // Points to the custom location of the Service Worker file.
    url: '/public/custom.sw.js'
  }
})

And another one: self.addEventListener('fetch', ...)
How can I prevent conflicts between my own fetchListener and msw's fetchListener?
I would like to write only one self.addEventListener('fetch', ...) where I could implement my logic and could append your logic.

[kettanaito]

how should I start msw worker?

You register the parent worker. In your case, it's your custom worker.

worker.start({
  serviceWorker: {
    url: '/public/custom.sw.js'
  }
})

How can I prevent conflicts between my own fetchListener and msw's fetchListener?

You'd have to experiment with the order of their execution. I suspect that if you define your listener first and then import the MSW worker, yours will get called first. From the listener, you'll be able to control whether to propagate the event further to the MSW worker or not.

// public/custom.sw.js
self.addEventListener('fetch', () => {
  // ...your logic

  if (something) {
    // I'd expect something like this to work.
    // You may also experiment with bubbling and short-cuircuting the listener. 
    event.stopPropagation()
  }
})

importSccript('./mockServiceWorker.js')

I only again stress that it's worth assessing if you really need a custom worker for development. Can you share more details on what you're intending to use this custom worker for? I can't imagine you need caching while developing, which is the primary use case for a service worker.

[crutch12]

@kettanaito Спасибо, Артём.

I've found out in example:

As soon as one handler calls event.respondWith(), none of the other registered handlers will be run.

So I should just intercept requests which are not for msw

self.addEventListener('fetch', () => {
  if (something) {
    event.respondWith(...)
  }
})

self.addEventListener('fetch', () => {
  // won't be called if something was true
})

---

First of all, I just wanted to figure out how to combine multiple service workers 😃
Of course I won't use production service workers while developing.

About my usage case
I want to use msw not just for development mocks but for production too.

In development

• I will mock any API to be possible start application without access to API server
• I will mock any/certain API to test application

In production

• I will mock missing APIs only.

We have a lot of situations when we already know API design and know future UI but the backend doesn't have time to implement it. So in this case I will mock missing API to be possible deploy it to stand and show how it looks like.

Also, I can continue developing the frontend. And when the backend implements that functionality, I'll just switch the flag for that mock from missing to implemented and it won't mock that API in production anymore.

Now I just return mocked data right before fetch if flag missing is provided.

async fetchSomething() {
  if (config.MOCK_API === 'missing') { // needed api is not implemented yet
    return timeout(500, []); // return fake data
  }

  // return real data
  return this.incidentsApi.get('/ui/incidents/')
}

So I want to rewrite it using msw

[arekucr]

Hi @crutch12 did u succeed integrating msw with your existing SW?

[crutch12]

@arekucr I didn't try
But in theory it should work with importScript('./mockServiceWorker.js')

[kettanaito]

I see no reason importScript would not work to combine multiple workers—it's designed to do that.

Pay close attention to handling the same events in both workers, though. As mentioned above, if multiple workers handle, for example, the fetch event, then it would work on a first-come-first-served basis. Account for that.

[bmarti44]

i've been taking a look at this - our use case is we would like to test out the service worker locally before sending it out to an environment. this would help prevent getting a rogue service worker installed on browser that would be hard to uninstall.

i have a working example ->

add to your webpack config

new InjectManifest({
        swSrc: './src/sw.js',
        swDest: './sw.js',
        maximumFileSizeToCacheInBytes: 10000000,
        exclude: [/\.ts$/, /\.tsx$/],
      })

src/sw.js ->

import { precacheAndRoute } from 'workbox-precaching';
import { registerRoute, Route } from 'workbox-routing';
import { CacheFirst } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';

const cdnRoute = new Route(
  ({ request }) => {
    return request.url.startsWith('https://cdn.com');
  },
  new CacheFirst({
    cacheName: 'cdn',
    plugins: [
      new ExpirationPlugin({
        maxAgeSeconds: 26495695,
      }),
    ],
  })
);

const stageCdnRoute = new Route(
  ({ request }) => {
    return request.url.startsWith('https://stage.cdn.com');
  },
  new CacheFirst({
    cacheName: 'stage-cdn',
    plugins: [
      new ExpirationPlugin({
        maxAgeSeconds: 26495695,
      }),
    ],
  })
);

registerRoute(cdnRoute);
registerRoute(stageCdnRoute);

precacheAndRoute(self.__WB_MANIFEST);

importScripts('/mockServiceWorker.js');

enabling it all ->

const { worker } = await import('../mocks/browser');
          await worker.start({
            serviceWorker: {
              url: '/sw.js',
            },
            onUnhandledRequest: 'bypass',
          });

the main problem i have is that msw must be enabled in order to use the service worker. while i want this locally so i can test everything, once we move to an environment, i want to only enable my production service worker.

i'm going through the code to start msw now, but, is there a way that i could conditionally start msw from my workbox service worker? from there i could probably send a message to the workbox service worker containing my environment variable for whether or not mocks should be enabled, and include the mock service worker script.

[kettanaito]

From the look of it, that is the correct way to compose two workers.

i'm going through the code to start msw now, but, is there a way that i could conditionally start msw from my workbox service worker?

You're starting MSW by calling worker.start(). If you don't call that function in your production environment, MSW will not start, and the imported worker script will do nothing. Simply call worker.start() conditionally:

// src/yourApp.js
// Start MSW's worker only in development.
if (process.env.NODE_ENV === 'development') {
  const { worker } = await import('./browser')
  await worker.start()
}

If you don't wish to include the worker script altogether, I recommend pre-compiling it to different environment targets, calling importScripts() conditionally in the source:

// sw.js

// This will come from your compiler, like webpack.
// The compiler will also be smart to remove this entire expression
// if the condition resolves to false.
if (process.env.NODE_ENV === 'development') {
  importScripts('./mockServiceWorker.js')
}

[bmarti44]

okay awesome that makes sense! thank you so much!