Workbox v6.1.0 includes a number of new features, as well as an important fix for a bug that could have affected workbox-precaching
behavior in earlier v6 releases.
🎉 What's New?
setCatchHandler for individual Routes
The setCatchHandler()
method on a Router
allows you to configure "fallback" logic if any handler invoked by that Router
returns an error. It can be awkward to use, however, if you have many different Route
s registered for the same Router
, and you would prefer that the fallback logic only be invoked when one or two particular Route
handlers fail.
Starting in this release, each individual Route
object has a setCatchHandler()
method, allowing you to add fallback logic just to that Route
, without affecting any other Route
s. To use this method, make sure you explicitly construct a Route
first, and then pass that Route
to the (overloaded) registerRoute()
method:
import {Route, registerRoute} from 'workbox-routing';
import {NetworkOnly, StaleWhileRevalidate} from 'workbox-strategies';
const navigationRoute = new Route(
({event, request, url}) => request.mode === 'navigate',
new NetworkOnly()
);
navigationRoute.setCatchHandler(
({event, request, url}) => {
// Do something to generate a fallback response,
// e.g. read a HTML document from the cache.
}
);
registerRoute(navigationRoute);
// This route, created implicitly via an overloaded registerRoute()
// method, won't have the catch handler applied.
registerRoute(
({event, request, url}) => request.destination === 'image',
new StaleWhileRevalidate()
);
See #2699
New "recipes"
The workbox-recipes
module has been extended with a few new features:
- A new recipe,
warmStrategyCache
, which takes an array of paths and a Workbox strategy and warms that strategy's cache with those paths at service worker install time. - Adds a
warmCache
option to page, image, and static resource recipes to allow users to warm those caches. - Adds a
plugins
option to page, image, and static resource recipes to allow users to pass additional plugins to those recipes, allowing a user, for instance, to add a URL normalization plugin to the page recipe.
The workbox-recipes
documentation has more information and examples.
See #2718
🐛 What's Fixed?
workbox-precaching
The expected behavior for workbox-precaching
is that all URLs listed in the precache manifest need to be considered "cacheable" in order for service worker installation to succeed. By default, workbox-precaching
considers any response with a status
code less than 400
as being cacheable (including opaque responses, which have a status code of 0
). Developers who need to customize this behavior can pass a cacheWillUpdate
plugin to workbox-precaching
, and use that logic to determine whether or not a response should be precached during installation.
Two bugs were introduced in the Workbox v6.0.0
release:
-
The default criteria, in which any response with a status of
400
or higher should be considered uncacheable, would lead to the invalid response being inadvertently written to the cache prior to failing the service worker installation. The next time installation was attempted, this previously cached error response wouldn't be retried, so after enough retries, the service worker would eventually finish installation, even though some responses that should have been considered invalid were precached. -
If a developer uses a
cacheWillUpdate
plugin while precaching, returningnull
from the plugin properly excluded that response from being precached, but it would not cause the overall service worker installation to fail.
Both of these bugs are fixed in the v6.1.0
release. During service worker installation, if any response that is uncacheable (either via the default or custom cacheWillUpdate
criteria) is encountered, installation will consistently fail and the invalid response won't be added to the cache.
See #2738
workbox-webpack-plugin
- Using the
chunks
orexcludeChunks
options could lead to a warning message under some circumstances, due toworkbox-webpack-plugin
assuming they always corresponded to chunk group names. The code will now check to see if the name matches a chunk itself, not just a group. See #2735
All build tools
- The
source-map
dependency has been updated to resolve an issue that could occur when run in a Node environment that had a polyfilledfetch()
. See #2716
Thanks!
Special thanks to @Spiderpig86 for contributing a PR that was part of this release.