(WEB_PORTAL) Adopting PWA in Next.js — When Service Worker Builds Collided with Turbopack
Overview
We worked on adding PWA (Progressive Web App) support to our internal web service so that users could add it to their mobile home screen and use it like a native app. We expected this to be a matter of installing a library and adding a few lines of configuration, but we ran into an unexpected conflict caused by a mismatch in build tool versions — this post shares that experience.
Why We Chose This Stack
- Starting with its latest versions, Next.js adopted Turbopack as the default dev server bundler, which significantly improved local development speed.
- For service worker generation, we decided to use a widely-used community PWA plugin for Next.js, since it let us minimize the configuration needed for manifest and service worker generation.
The Problem
There was no issue when running the local dev server (next dev), but the production build (next build)
failed. Investigating the cause, we found that the PWA plugin we'd adopted still generated the service worker
using a Webpack plugin approach, which was incompatible with Turbopack, the bundler Next.js uses by default.
In other words, the dev server didn't surface the problem because the service worker itself is disabled in development mode — but at production build time, the bundler mismatch caused an outright failure.
The Fix
We added an option to the Next.js production build command that explicitly forces the Webpack bundler, so that only the build step switches over to Webpack.
Run dev server: next dev → Uses Turbopack (unchanged)
Run production build: next build --webpack → Switches to Webpack for this build only
This kept our development productivity intact while separating out the responsibility: only the deployment build uses the bundler that's compatible with the PWA plugin.
Retrospective
- We confirmed that even when a new bundler is rapidly gaining adoption, if the surrounding ecosystem (plugins) hasn't fully caught up yet, a pragmatic compromise of "picking the right tool per use case" is safer than "standardizing everything on the new bundler."
- We've since developed the habit of thinking about the dev and deployment bundling pipelines as separate concerns whenever a similar build tool transition issue comes up.