workbox-build 6.1.0

Workbox v6.1.0

on Node.js NPM

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 Routes 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 Routes. 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, returning null 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 or excludeChunks options could lead to a warning message under some circumstances, due to workbox-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 polyfilled fetch(). See #2716

Thanks!

Special thanks to @Spiderpig86 for contributing a PR that was part of this release.