@ibash/next-service-worker

next-service-worker

Add a service worker powered by Workbox to your Next.js application

What is this? 🧐

A minimal wrapper around Workbox to quickly add a service worker to your Next.js application. Get all of the power of workbox without needing to manage webpack directly!

Installation & Usage 📦

• Add this package to your project:

  yarn add next-service-worker

• Update your next.config.js:

  const withServiceWorker = require("next-service-worker");
  
  module.exports = withServiceWorker({
    // next config here...
  
    serviceWorker: {
      // service worker config here...
  
      workbox: {
        // workbox config here...
      },
    },
  });
  

API Overview 🛠

Name	Description	Type
enableInDevelopment	Enable the service worker in local development. Depending on your service worker configuration, this can be problematic for developer workflows where you end up serving outdated cached files. If false then a placeholder service worker will be generated, which will immediately clear any previously installed service workers that may have been installed previously such as testing a production build locally. Defaults to false. Recommended: false for general development, true for first time setup and when debugging your application's service worker.	boolean | undefined
enableWorkboxLogging	Enable workbox logging. Workbox logging is both very helpful and very chatty. By default, workbox will use the webpack mode to determine whether or not to enable workbox logging. When the mode is production, then logging is disabled. Otherwise, logging is enabled. Setting this to true enables workbox logging when the webpack mode is set to production. Setting this to false will disable workbox logging, which is likely preferred when not debugging your servicer worker. Note: This option is only relevant when using the service worker generated by workbox. It does not apply to the development service worker generated when enableInDevelopment is false, or if you supply your own service worker via workbox's swSrc field. Defaults to unset, falling back on the workbox behavior. Recommended: false for general development, true for first time setup and when debugging your application's service worker.	boolean | undefined
registration.autoRegister	Autoregister the service worker. If false, then the application must initialize the service worker by invoking register. Set this to false if you'd like to take control over when you service worker is initialized. You'll then need to add something like the following to your application: import { Workbox } from "workbox-window"; if ("serviceWorker" in navigator) { const wb = new Workbox("/path-to-your-service-worker.js"); wb.register(); } Defaults to true. Recommended: true.	boolean | undefined
registration.path	The registration path tells the browser where your service worker is located. Defaults to /service-worker.js.	string | undefined
registration.scope	The scope of the service worker determines which files the service worker controls, in other words, from which path the service worker will intercept requests. The default scope is the location of the service worker file, and extends to all directories below. So if service-worker.js is located in the root directory, the service worker will control requests from all files at this domain. Defaults to your next.config.js basePath.	string | undefined
workbox	Options passed to worbox-webpack-plugin. See all available configuration options here. Defaults to GenerateSW which will generate a service worker with the workbox runtime included.	InjectManifestOptions | GenerateSWOptions

Examples 🚀

Check out the next-service-worker-example. The only change from the default NextJS setup is the addition of next.config.js!

Common Service Worker Pitfalls ⚠️

You must serve your next application over HTTPS in production environments. Service Workers must be served from the site's origin over HTTPS.

Most browsers make special case localhost, so this is generally not necessary during local development. HTTPS is not handled by this library.

The service worker origin constraint means that the service worker can not control mysite.com if it was served from a subdomain such as mycdn.mysite.com. If you serve from Next's public folder, things will work out of the box. If you move Next's public folder contents to a CDN and serve the service worker from that CDN additional configuration may be necessary.

Related Projects

• Next PWA

• Next Offline

Highlights

🪠 Handles the NextJS specific plumbing for you so you can focus on your application!

Contributing 👫

PR's and issues welcomed! For more guidance check out CONTRIBUTING.md

Licensing 📃

See the project's MIT License.