Split dependencies when using InjectManifest strategy

[filips123]

I need to set up service worker that uses Firebase Cloud Messaging (FCM) for push notifications, so I have to use the InjectManifest strategy. I would also like to write the service worker in TypeScript.

In the initial version, I've simply used the following service worker code from the documentation:

import { precacheAndRoute } from 'workbox-precaching'

precacheAndRoute(self.__WB_MANIFEST)

The service worker generates fine. However, the problem is that all dependencies (currently just workbox) are now bundled in the same sw.js file. As service worker doesn't use hash-based filenames, this means I will be unable to apply the optimal HTTP caching strategy. In comparison, when using the default GenerateSW strategy, the workbox code is split into a separate workbox-hash.js file that is imported from sw.js and can be cached separately.

I would like to apply the same thing to the custom InjectManifest-based service worker. For example, that workbox dependency is stored in the sw-workbox-hash.js file, and that firebase dependency is in the sw-firebase-hash.js.

My first attempt was using the configureCustomSWViteBuild option:

    integration: {
       configureCustomSWViteBuild: (viteConfig) => {
        viteConfig.build.rollupOptions.output = {
          ...viteConfig.build?.rollupOptions?.output,
          manualChunks: {
            firebase: ['firebase/app', 'firebase/messaging'],
            workbox: ['workbox-core', 'workbox-precaching', 'workbox-routing']
          },
          chunkFileNames: 'sw-[name].[hash].js',
          inlineDynamicImports: false
        }
      },
    },

This correctly splits workbox into a separate sw-workbox-hash.js file. The problem now is that the file is imported from the main service worker file using ES modules, which is not supported in all browsers. Additionally, the filename hash doesn't respect the global hashCharacters Vite/Rollup option (which it did when using GenerateSW strategy).

I tried to solve the first problem by setting the output format to IIFE:

    injectManifest: {
      rollupFormat: 'iife'
    },

But that fails the build:

Invalid value "iife" for option "output.format" - UMD and IIFE output formats are not supported for code-splitting builds.

Interestingly, GenerateSW generates split builds just fine without using ES modules.

So, is it possible to split service worker dependencies into own files and import them without ES modules, while preferably respecting global Vite/Rollup options (such as hashCharacters)?

[userquin]

check https://github.com/vite-pwa/vite-plugin-pwa/blob/main/src/vite-build.ts

you can use also integration?.configureCustomSWViteBuild callback where we provide the vite inline options before calling vite build api

[filips123]

Well, I already tried that, but I don't know how to configure it so it uses split files without using ES modules for importing.

[userquin]

no idea why you need/want to split the chunks, we don't build the sw for ESM, it is just a hack and we always register the sw via type classic (using any virtual module), the build should work fine (npm add -D @firebase/app-compat @firebase/messaging-compat or using modular instead namespaced libraries, check code below => with modular library 210KB , with namespaced 275KB):

Discord server invitation: https://discord.gg/YJ8NNX9S

https://discord.com/channels/937808017016119440/937973377883336704/1332100478431006750

generateSW at workbox doesn't need bundling, it is using importScripts, when using injectManifest we need first build the service worker via Vite, then inject the injectionPoint via injectManifest from workbox build module, check this https://vite-pwa-org.netlify.app/guide/cookbook.html#vite-plugin-pwa-closebundle-hook

import { initializeApp } from '@firebase/app'
import { getMessaging, onBackgroundMessage, isSupported } from '@firebase/messaging/sw'

const app = initializeApp({
  apiKey: import.meta.env.VITE_FIREBASE_API_KEY ?? 'some-key',
  authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN ?? 'some-domain',
  projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID  ?? 'some-project',
  storageBucket: import.meta.env.VITE_FIREBASE_STORAGE_BUCKET ?? 'some-sotrage',
  messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID  ?? 'some-sender',
  appId: import.meta.env.VITE_FIREBASE_APP_ID ?? 'some-app',
})

console.log('messaging supported', isSupported())

const messaging = getMessaging(app)

onBackgroundMessage(messaging, (payload) => {
  const notification = payload.notification;
  if (!notification) return;
  const notificationTitle = notification.title;
  const notificationOptions = {
    body: notification.body,
    icon: '/pwa-192-192.png',
  };

  self.registration.showNotification(notificationTitle || 'Unknown title', notificationOptions);
});

[filips123]

no idea why you need/want to split the chunks

Isn't it better to have dependencies split into separate files with hash-based filenames that can be cached for a long time? So, dependencies don't have to be redownloaded every thime an app up updated, as long as they remain at the same version? And 210KB for firebase (+ 15 KB for workbox) seems quite a lot for a single-file service worker without a hash-based filename.

Also, as GenerateSW also splits workbox into its own file, I expected the same to be possible with InjectManifest.

generateSW at workbox doesn't need bundling, it is using importScripts

Well, it seems that when using GenerateSW, the service worker imports the workbox file using some loader code (that then uses importScripts or script tag), but that file is stored locally and properly minified:

if (!self.define) {
  let e, s = {}
  const i = (i, c) => (i = new URL(i + '.js', c).href, s[i] || new Promise((s => {
    if ('document' in self) {
      const e = document.createElement('script')
      e.src = i, e.onload = s, document.head.appendChild(e)
    } else e = i, importScripts(i), s()
  })).then((() => {
    let e = s[i]
    if (!e) throw new Error(`Module ${i} didn’t register its module`)
    return e
  })))
  self.define = (c, d) => {
    const r = e || ('document' in self ? document.currentScript.src : '') || location.href
    if (s[r]) return
    let a = {}
    const b = e => i(e, r), n = { module: { uri: r }, exports: a, require: b }
    s[r] = Promise.all(c.map((e => n[e] || b(e)))).then((e => (d(...e), a)))
  }
}
define(['./workbox-258b578c'], (function(e) {
  'use strict'
  // Actual code
}))

But when I tried to also use importScripts in my service worker:

importScripts('workbox-sw')

workbox.precaching.precacheAndRoute(self.__WB_MANIFEST)

Vite didn't do any processing and just copied the importScripts('workbox-precaching') line into the built service worker.

So, is it possible to somehow import dependencies when using InjectManifest, so they are still properly built/minified into separate files and imported using the same import mechanism, like when using GenerateSW?

[userquin]

Maybe you can create a workbox recipe and use it via generateSW strategy.

IIRC workbox will check byte by byte the sw to check if there is a new version, and so, you should use always 200 for the sw and maybe also for the dependencies if any (workbox-**), no idea if workbox will also download the workbox-** file to check it; if workbox downloads also the workbox-**, no makes sense to split the sw into chunks.

[filips123]

Maybe you can create a workbox recipe and use it via generateSW strategy.

Is it possible to include a custom workbox recipe into a generated manifest?

Also, how does generateSW strategy then have split workbox file? Is that handled internally in workbox-build, without the ability to re-use it for custom manifests?