Next.js with PWA, powered by workbox. – Next 13 App directory support
npm install @murkrage/next-pwaI have only made a minor change to this to ensure the app directory works. Will remove this package when Shadowwalker's package has been updated to support the app directory.
This plugin is powered by workbox and other good stuff.
!size !dependencies !downloads !license
👋 Share your awesome PWA project 👉 here
Features
- 0️⃣ Zero config for registering and generating service worker
- ✨ Optimized precache and runtime cache
- 💯 Maximize lighthouse score
- 🎈 Easy to understand examples
- 📴 Completely offline support with fallbacks example 🆕
- 📦 Use workbox and workbox-window v6
- 🍪 Work with cookies out of the box
- 🔉 Default range requests for audios and videos
- ☕ No custom server needed for Next.js 9+ example
- 🔧 Handle PWA lifecycle events opt-in example
- 📐 Custom worker to run extra code with code splitting and typescript support example
- 📜 Public environment variables available in custom worker as usual
- 🐞 Debug service worker with confidence in development mode without caching
- 🌏 Internationalization (a.k.a I18N) with next-i18next example
- 🛠 Configurable by the same workbox configuration options for GenerateSW and InjectManifest
- 🚀 Spin up a GitPod and try out examples in rocket speed
- ⚡ Support blitz.js (simply add to blitz.config.js)
- 🔩 (Experimental) precaching .module.js when next.config.js has experimental.modern set to true
> NOTE 1 - next-pwa version 2.0.0+ should only work with next.js 9.1+, and static files should only be served through public directory. This will make things simpler.
>
> NOTE 2 - If you encounter error TypeError: Cannot read property 'javascript' of undefined during build, please consider upgrade to webpack5 in next.config.js.
---
> If you are new to next.js or react.js at all, you may want to first checkout learn next.js or next.js document. Then start from a simple example or progressive-web-app example in next.js repository.
``bash`
yarn add next-pwa
Update or create next.config.js with
`javascript
const withPWA = require("next-pwa")({
dest: "public",
});
module.exports = withPWA({
// next.js config
});
`
After running next build, this will generate two files in your public: workbox-*.js and sw.js, which will automatically be served statically.
If you are using Next.js version 9 or newer, then skip the options below and move on to Step 2.
If you are using Next.js older than version 9, you'll need to pick an option below before continuing to Step 2.
Copy files to your static file hosting server, so that they are accessible from the following paths: https://yourdomain.com/sw.js and https://yourdomain.com/workbox-*.js.
One example is using Firebase hosting service to host those files statically. You can automate the copy step using scripts in your deployment workflow.
> For security reasons, you must host these files directly from your domain. If the content is delivered using a redirect, the browser will refuse to run the service worker.
When an HTTP request is received, test if those files are requested, then return those static files.
Example server.js
`javascript
const { createServer } = require("http");
const { join } = require("path");
const { parse } = require("url");
const next = require("next");
const app = next({ dev: process.env.NODE_ENV !== "production" });
const handle = app.getRequestHandler();
app.prepare().then(() => {
createServer((req, res) => {
const parsedUrl = parse(req.url, true);
const { pathname } = parsedUrl;
if (
pathname === "/sw.js" ||
/^\/(workbox|worker|fallback)-\w+\.js$/.test(pathname)
) {
const filePath = join(__dirname, ".next", pathname);
app.serveStatic(req, res, filePath);
} else {
handle(req, res, parsedUrl);
}
}).listen(3000, () => {
console.log(> Ready on http://localhost:${3000});`
});
});
> The following setup has nothing to do with next-pwa plugin, and you probably have already set them up. If not, go ahead and set them up.
Create a manifest.json file in your public folder:
`json`
{
"name": "PWA App",
"short_name": "App",
"icons": [
{
"src": "/icons/android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png",
"purpose": "any maskable"
},
{
"src": "/icons/android-chrome-384x384.png",
"sizes": "384x384",
"type": "image/png"
},
{
"src": "/icons/icon-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"theme_color": "#FFFFFF",
"background_color": "#FFFFFF",
"start_url": "/",
"display": "standalone",
"orientation": "portrait"
}
Add the following into _document.jsx or _app.tsx, in
:`html
sizes="152x152"
href="/icons/touch-icon-ipad.png"
/>
sizes="180x180"
href="/icons/touch-icon-iphone-retina.png"
/>
sizes="167x167"
href="/icons/touch-icon-ipad-retina.png"
/>
type="image/png"
sizes="32x32"
href="/icons/favicon-32x32.png"
/>
type="image/png"
sizes="16x16"
href="/icons/favicon-16x16.png"
/>
href="https://fonts.googleapis.com/css?family=Roboto:300,400,500"
/>
content="https://yourdomain.com/icons/android-chrome-192x192.png"
/>
content="https://yourdomain.com/icons/apple-touch-icon.png"
/>
`> Tip: Put the
head meta tag into _app.js rather than in _document.js if you need it.`typescript
content="minimum-scale=1, initial-scale=1, width=device-width, shrink-to-fit=no, user-scalable=no, viewport-fit=cover"
/>
`Offline Fallbacks
Offline fallbacks are useful when the fetch failed from both cache and network, a precached resource is served instead of present an error from browser.
To get started simply add a
page such as pages/_offline.js or pages/_offline.jsx or pages/_offline.ts or pages/_offline.tsx. Then you are all set! When the user is offline, all pages which are not cached will fallback to '/\_offline'.next-pwa helps you precache those resources on the first load, then inject a fallback handler to handlerDidError plugin to all runtimeCaching configs, so that precached resources are served when fetch failed.You can also setup
precacheFallback.fallbackURL in your runtimeCaching config entry to implement similar functionality. The difference is that above method is based on the resource type, this method is based matched url pattern. If this config is set in the runtimeCaching config entry, resource type based fallback will be disabled automatically for this particular url pattern to avoid conflict.Configuration
There are options you can use to customize the behavior of this plugin by adding
pwa object in the next config in next.config.js:`javascript
const withPWA = require("next-pwa")({
dest: "public",
// disable: process.env.NODE_ENV === 'development',
// register: true,
// scope: '/app',
// sw: 'service-worker.js',
//...
});module.exports = withPWA({
// next.js config
});
`$3
- disable: boolean - whether to disable pwa feature as a whole
- default:
- set , so that it will generate service worker in both dev and prod
- set to completely disable PWA
- if you don't need to debug service worker in dev, you can set disable: process.env.NODE_ENV === 'development'
- register: boolean - whether to let this plugin register service worker for you
- default to
- set to when you want to handle register service worker yourself, this could be done in componentDidMount of your root app. you can consider the register.js as an example.
- scope: string - url scope for pwa
- default: basePath in next.config.js or /
- set to so that path under /app will be PWA while others are not
- sw: string - service worker script file name
- default: /sw.js
- set to another file name if you want to customize the output file name
- runtimeCaching - caching strategies (array or callback function)
- default: see the Runtime Caching section for the default configuration
- accepts an array of cache entry objects, please follow the structure here
- Note: the order of the array matters. The first rule that matches is effective. Therefore, please ALWAYS put rules with larger scope behind the rules with a smaller and specific scope.
- publicExcludes - an array of glob pattern strings to exclude files in the folder from being precached.
- default: ['!noprecache/*/'] - this means that the default behavior will precache all the files inside your public folder but files inside /public/noprecache folder. You can simply put files inside that folder to not precache them without config this.
- example: ['!img/super-large-image.jpg', '!fonts/not-used-fonts.otf']
- buildExcludes - an array of extra pattern or function to exclude files from being precached in (or your custom build) folder
- default: []
- example: - Don't precache files under .next/static/chunks/images (Highly recommend this to work with next-optimized-images plugin)
- doc: Array of (string, RegExp, or function()). One or more specifiers used to exclude assets from the precache manifest. This is interpreted following the same rules as Webpack's standard exclude option.
- cacheStartUrl - whether to cache start url
- default: true
- discussion of use case to not cache start url at all
- dynamicStartUrl - if your start url returns different HTML document under different state (such as logged in vs. not logged in), this should be set to true.
- default:
- effective when set to true
- recommend: set to false if your start url always returns same HTML document, then start url will be precached, this will help to speed up first load.
- dynamicStartUrlRedirect - if your start url redirect to another route such as , it's recommended to setup this redirected url for the best user experience.
- default: undefined
- effective when set to true
- fallbacks - config precached routes to fallback when both cache and network not available to serve resources.
- if you just need a offline fallback page, simply create a page such as pages/_offline.js and you are all set, no configuration necessary
- default: object
- - fallback route for document (page), default to /_offline if you created that page
- fallbacks.image - fallback route for image, default to none
- fallbacks.audio - fallback route for audio, default to none
- fallbacks.video - fallback route for video, default to none
- fallbacks.font - fallback route for font, default to none
- cacheOnFrontEndNav - enable additional route cache when navigate between pages with next/link on front end. Checkout this example for some context about why this is implemented.
- default: false
- note: this improve user experience on special use cases but it also adds some overhead because additional network call, I suggest you consider this as a trade off.
- ~~subdomainPrefix: string - url prefix to allow hosting static files on a subdomain~~
- ~~default: - i.e. default with no prefix~~
- ~~example: /subdomain if the app is hosted on example.com/subdomain~~
- deprecated, use basePath instead
- reloadOnOnline - changes the behaviour of the app when the device detects that it has gone back "online" and has a network connection. Indicate if the app should call location.reload() to refresh the app.
- default: true
- customWorkerDir - customize the directory where looks for a custom worker implementation to add to the service worker generated by workbox. For more information, check out the custom worker example.
- default: worker$3
uses workbox-webpack-plugin, other options which could also be put in pwa object can be found ON THE DOCUMENTATION for GenerateSW and InjectManifest. If you specify swSrc, InjectManifest plugin will be used, otherwise GenerateSW will be used to generate service worker.$3
next-pwa uses a default runtime cache.jsThere is a great chance you may want to customize your own runtime caching rules. Please feel free to copy the default
cache.js file and customize the rules as you like. Don't forget to inject the configurations into your pwa config in next.config.js.Here is the document on how to write runtime caching configurations, including background sync and broadcast update features and more!
Tips
1. Common UX pattern to ask user to reload when new service worker is installed
2. Use a convention like
{command: 'doSomething', message: ''} object when postMessage to service worker. So that on the listener, it could do multiple different tasks using if...else....
3. When you are debugging service worker, constantly clean application cache to reduce some flaky errors.
4. If you are redirecting the user to another route, please note workbox by default only cache response with 200 HTTP status, if you really want to cache redirected page for the route, you can specify it in runtimeCaching such as options.cacheableResponse.statuses=[200,302].
5. When debugging issues, you may want to format your generated sw.js file to figure out what's really going on.
6. Force next-pwa to generate worker box production build by specify the option mode: 'production' in your pwa section of next.config.js. Though next-pwa automatically generate the worker box development build during development (by running next) and worker box production build during production (by running next build and next start). You may still want to force it to production build even during development of your web app for following reason:
1. Reduce logging noise due to production build doesn't include logging.
2. Improve performance a bit due to production build is optimized and minified.
7. If you just want to disable worker box logging while keeping development build during development, simply put self.__WB_DISABLE_DEV_LOGS = true in your worker/index.js (create one if you don't have one).
8. It is common developers have to use userAgent` string to determine if users are using Safari/iOS/MacOS or some other platform, ua-parser-js library is a good friend for that purpose.1. Google Workbox
2. ServiceWorker, MessageChannel, & postMessage by Nicolás Bevacqua
3. The Service Worker Lifecycle
4. 6 Tips to make your iOS PWA feel like a native app
5. Make Your PWA Available on Google Play Store
1. Experience SAMSUNG on an iPhone - must open on an iPhone to start
2. App Scope - like an app store for PWA
3. PWA Directory
4. PWA Builder - Alternative way to build awesome PWA
MIT