The latest beta release of Workbox v4 includes the following developer-visible changes, in addition to all the changes from the previous pre-releases.

🎉 What's New?

workbox-window

• The Workbox constructor function signature has changed to accept an optional scriptVersion option. To support this new option (and other future options) the constructor now accepts a single object argument [#1861].

// Old way
new Workbox(scriptURL, registerOptions);

// New way 
new Workbox({
  scriptUrl,
  scriptVersion,
  registerOptions,
});

• The properties .active and .controlling have been added to the Workbox class. These are promises which will resolve as soon as Workbox has a reference to a service working in the corresponding state (active or controlling) with a matching scriptURL (and optionally scriptVersion, if used). These are similar to the navigator.serviceWorker.ready promise, but when using scriptVersion you can be sure they won't resolve until the correct version of the script is active/controlling [#1861].

• Workbox event listeners are now always called with an Event-like object (i.e. they have a .type, .target properties), to more closely match how native event listeners work. In the future when all browsers support contructable EventTarget, these will be native Event objects [#1861].

// Old way
myWorkbox.addEventListener('activated', (sw) => {
  // Do something with `sw`.
});

// New way 
myWorkbox.addEventListener('activated', (event) => {
  // The activated service worker is at `event.sw`.
  // And the underlying event that triggered this is at `event.originalEvent`.
});

• The controlling event is now dispatched prior to the activated event, which correctly matches the ordering of when the controllerchange and statechange events fire in the service worker lifecycle. [#1861]

workbox-routing

• The workbox.routing.Router#addCacheListener() method has updated the format off messages it can receive from the window to cache. Previously it would accept an array of URL strings, now it can also accept an array of URL strings or arrays in the form of [url, requestInit]. This is useful if you need to override the default request mode [#1851]

Build tools

• Support for a new boolean configuration option, cleanupOutdatedCaches, has been added to the GenerateSW mode of all of the build tools. It defaults to false. When set to true, a call to workbox.precaching.cleanupOutdatedCaches() will automatically be added to your generated service worker, which will in turn delete any out-of-date precaches no longer used by Workbox. Workbox v4 introduced a breaking change to the precache format, so developers upgrading from Workbox v3 or earlier might find this useful. [#1863]

🐛 What's Fixed?

workbox-webpack-plugin

• In addition to swSrc being a file on file system, it can now be a webpack generated asset as well. This allows users to compile their service worker with webpack and then give it as a source to inject-manifest plugin. [#1763]

workbox-core

• Don't set fetchOptions when request.mode is 'navigate', to work around an issue that could lead to failed navigations. [#1862]

Workbox v4.0.0-beta.1 Release Notes

The latest beta release of Workbox v4 includes the following developer-visible changes, in addition to all the changes from the previous pre-releases.

🎉 What's New?

The workbox-windowpackage

The workbox-window, a library which can be used from the context of your web page (i.e. the window global scope). It provides helpers for registering and detecting updates to your service worker. Functionality will be added over time, and we're looking for early feedback. (#1827)

You can try out workbox-window in dev mode today by adding the following module script to your HTML templates. But be sure change the URL to workbox-window.prod.mjs before deploying your code to production!

<script type="module">
// Important: change the filename to workbox-window.prod.mjs before deploying.
import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/4.0.0-beta.1/workbox-window.dev.mjs'

new Workbox('/sw.js').register();
</script>

For additional usage instructions and API reference, see the design doc.

Other new features:

• workbox-cli now supports a --watch parameter. When used, it will re-run the service worker build whenever any of the files in the precache manifest change. (#1776)

• Support for including JavaScript functions when configuring runtimeCaching in the various build tools. (#1770 and #1778)

• The workbox-webpack-plugin will append to, rather than overwrite, any existing self.__precacheManifest value, making it easier to combine a precache manifest with the manifest generated by the plugin. (#1775)

• A new fetchDidSucceed({request, response}) lifecycle callback has been added, allowing developers to inspect and potentially modify a response that's been retrieved from the network, prior to it being passed back to the page. (#1772)

• The default check for whether a response is cacheable now looks explicitly for a status code of 200, rather than checking for response.ok (which is true for any status code in the range 200-209). In practice, this means that partial responses with a status code of 206 won't be inadvertently cached by default. (#1805)

• The default injectionPointRegexp option value has been updated to exclude a leading . character, making it friendlier to developers who are bundling their own service worker files. (#1834)

• Several under-the-hood changes have been made to Workbox's internal build and bundling structure, which should not impact developers using the default, prepackaged libraries. (#1831)

⚠️ Breaking Changes

workbox-precaching rewrite

workbox-precaching has undergone a major rewrite (#1820) to address the issues detailed in #1793. As a result, existing precached data used by Workbox prior to this beta release can't be reused, and upon registering a service worker that uses this new code, all precached data will be downloaded again.

Changes to cache keys

Entries that are precached will now store any revision information provided in the precache manifest as a special URL query parameter, __WB_REVISION__, appended to the entry's real URL. In practice, that means that a precache entry with a URL of /index.html and revision of abcd1234 would be cached with a key of /index.html?__WB_REVISION__=abcd1234.

If you are using workbox-precaching via the precacheAndRoute() interface, as most developers are, the details of looking up the correct cache key will be handled for your automatically.

If you have a need to manually retrieve a precached entry directly using caches.match(), then you have two options:

• Use the "real" URL, and pass in the ignoreSearch parameter to caches.match(). This does not give you any guarantees about which version of the cached resource you'll retrieve.

• Pass the "real" URL to workbox.precaching.getCacheKeyForURL(), which will return the cache key corresponding to the version of the resource cached by the current service worker. You can then pass this cache key directly to caches.match(). This is the safest approach.

Cleaning up old precached data

After upgrading to the latest Workbox v4.0.0-beta.1 release, any precached data stored by a previous version of Workbox will effectively be "abandoned". Workbox will not attempt to delete outdated precaches, as doing so involves some degree of guessing what the previous precache name was.

A new method, workbox.precaching.cleanupOutdatedCaches() can be manually called if you would like to opt-in to an attempt at cleaning up the correct cache.

Alternatively, if you know the name of your old precache, you can explicitly call caches.delete('old-precache-name') inside of an activate handler instead.

We are looking for feedback about how workbox.precaching.cleanupOutdatedCaches(), as a future release might default to enabling it instead of requiring developers to opt-in to using it.

Removal of workbox.precaching.supressWarnings()

A call to this method was generated by the build tools to turn off some warning messages that might otherwise be logged. This proved unnecessary, and for simplicity's sake, workbox.precaching.supressWarnings() has been removed from Workbox.

Other breaking changes:

• Workbox log levels have been removed since now all developer tools support filtering visible logs by level. As a result, workbox.core.setLogLevel(), workbox.core.logLevel, and workbox.core.LOG_LEVELS have all been removed.

• Workbox previously allowed developers to use workbox-strategies in one of two ways: by calling a workbox.strategies.strategyName() factory method, or by explicitly constructing new workbox.strategies.StrategyName(). To avoid confusion, the workbox.strategies.strategyName() approach is deprecated, and will be removed in v5. We encourage all developers to move to the new workbox.strategies.StrategyName() syntax. (#1842)

• Various public interfaces and options have been renamed to standardize on capitalization. Most noticeably, 'Url' is now 'URL', 'Sw' is now 'SW', and the various strategyName handler values in runtimeCaching are now StrategyName (e.g. 'cacheFirst' is now 'CacheFirst'). The previous capitalization will remain supported until Workbox v5, but using the old variation will lead to deprecation warnings. All developers are encouraged to update their configuration to match the new, consistent capitalization. (#1833 and #1841)

• workbox.skipWaiting() has been renamed to workbox.core.skipWaiting(), and workbox.clientsClaim() has been renamed to workbox.core.clientsClaim(). If you are using the skipWaiting or clientsClaim build configuration options, the new method names will be used in your generated service worker automatically.

🐛 What's Fixed?

• Using fetchOptions to customize the behavior of a network request (e.g., by adding in an extra header) will now work when the request has a mode of 'navigate'. (#1825)

Thanks!

Special thanks to @tanhauhau for contributions that went into this release.

The first beta release of Workbox v4 includes the following developer-visible changes from the previous alpha release.

🎉 What's New?

• [BREAKING CHANGE] The workbox.backgroundSync.Queue class has been updated to give developers much control over how failed requests are replayed when a sync event occurs. Previously, developers could only add requests to the queue (there was no option to remove them). Now they have low-level methods to push, pop, shift, and unshift requests. For the full list of changes and use cases, see #1710.

• [BREAKING CHANGE] workbox-precaching will default to confirming that all Responses cached during installation have a non-error (less than 400) HTTP status code. If any Responses have an error code, the install phase will now fail. (The next time the service worker starts up, installation will be re-attempted.) Developers who need to precache Responses that have a 4xx or 5xx status code (e.g., precaching a /not-found.html URL that is served with a status code of 404) can opt-in to allowing that by passing in a custom cacheWillUpdate plugin to the workbox.precaching.PrecacheController's install method.

• [BREAKING CHANGE] workbox-range-requests will now check to see if the Response object it's processing already has an HTTP status code of 206 (indicating that it contains partial content). If so, it will just pass it through unmodified. (#1721)

• workbox.routing.Router now includes a routes getter method, giving developers access to the underlying Map of routes that have been registered for a given router. (#1714)

• Improved logging when using workbox.routing.NavigationRoute. When a URL matches the blacklist, there's now a message logged with higher priority when using the development builds. (#1741)

• When using workbox-precaching, the temporary cache is now cleaned up following service worker activation. (#1736)

Overview of Workbox v4

We're happy to announce the first alpha release of Workbox's v4! This release brings a relatively small number of breaking changes, and we anticipate a straightforward migration for most developers. Here's what to watch out for:

🎉 What's New?

workbox-routing logic can now be used outside of a fetch event

Most of the time a workbox router instance is responding to a fetch event by matching that event's request against the list of registered routes. But there are some cases where you want to reuse your existing routing and caching strategy logic outside of receiving fetch events. The two most common use cases are:

• Caching URLs that were fetched prior to the service worker controlling the page.
• Pre-caching URLs that you think the user will likely need in the near future.

The Router class's handleRequest() method now takes an object in the form of {request, [event]} (where event is optional). When called, the router will then make and cache the request according to whatever caching strategies/plugins are used by the matching route.

Note: the use cases described above are different from pre-caching via workbox-precaching in that they're resources that can best be determined at runtime. workbox-precaching, on the other hand, should be used for caching resources that can best be determined at build time.

See #1682 for details.

workbox-broadcast-cache-update no longer requires the Broadcast Channel API and defers notifications on navigation requests

The workbox-broadcast-cache-update library would previously only work in browsers that supported the Broadcast Channel API. Nothing would happen when it was used in browsers that lacked support.

Starting in v4, the code will automatically fall back to iterating over all the open window clients and sending them an update message, one by one, using the postMessage() API.

In addition, when the workbox-broadcast-cache-update plugin would detect updates for navigation requests, most of the time the page the user is navigating to will not be ready to receive the update notification at the time when it's sent. To help deal with this issue, the plugin now defers notifications on navigation requests until a configurable timeout has passed, or until it receives a ready signal from the window.

See #1673 for details.

MIT Licensing

Workbox has moved from using the Apache 2 license to the MIT license. The motivation is similar to what led Angular to previously make the same switch.

⚠️ Breaking Changes

Modern transpilation targets

Workbox uses the (excellent) Babel project, along with @babel/preset-env, to transpile our source code to various runtime targets.

For Workbox libraries that run in a node environment (e.g. workbox-build, workbox-cli, and workbox-webpack-plugin), we've updated the transpilation target to node version 6. This means we've dropped compatibility with node version 4, which has reached its official end-of-life date. (#1654)

For Workbox libraries that run in the service worker environment (e.g. workbox-sw, and all the other runtime code), we've updated the transpilation target to Chrome 56. We chose this target because it matches the capabilities of Samsung Internet v6 and higher. This means we've dropped compatibility with any browser based on Chrome versions earlier than 56, like Samsung Internet v5. (#1655)

Our intention is to be fully compatible with all "evergreen" browsers, including Chrome, Firefox, Edge, or Safari.

Standard failure behavior for the various workbox-strategies

Previously, the various workbox-strategies would behave differently in failure scenarios. Some, like networkFirst, would resolve with an undefined value when there was a network failure and a cache miss. Other strategies would reject with a NetworkError under a similar failure.

Starting in v4, we've standardized how all of the workbox-strategies behave when they can't return a response due to some combination of network failure and/or cache miss: the promise than they return will consistently reject with a WorkboxError. This makes it much easier to think about handling failures with "fallback content," making patterns using custom handlers like the following work consistently, regardless of the strategy being used. (#1657)

workbox.routing.registerRoute(
  new RegExp('/some/path/prefix'),
  async ({event}) => {
    try {
      return await workbox.strategies.networkFirst().handle({event});
    } catch (error) {
      return caches.match(FALLBACK_URL);
    }
  }
);

workbox-webpack-plugin will now precache manifest.json by default

Previously, the default configuration would cause workbox-webpack-plugin to exclude files named manfiest.json from the list of files to precache. Because some browsers do in fact make use of the service worker cache when reading the web app manifest data, it makes more sense to default to including, rather than excluding, that file. (#1679)

🐛 What's Fixed?

Windows command line compatibility

As a byproduct of updating our projects various npm dependencies to the latest releases, we've fixed and issue that preventing the workbox-cli's wizard command from properly completing when run on a Windows command line environment. (#1658)

Precaching of HTTP 30x redirects

A bug in workbox-precaching previously could have caused URLs that lead to a HTTP 30x redirect to be cached incorrectly. This is now fixed. (#1678)

Failed service worker installations due to workbox-google-analytics

Certain content blocking browser extensions automatically cause calls like importScripts('/path/to/workbox-google-analyics.prod.js)to fail. That failure, in turn, will prevent a service worker from ever successfully installing. To prevent this trickle-down failure scenario, we've renamed the workbox-google-analytics.prod.js and workbox-google-analytics.dev.js to workbox-offline-ga.prod.js and workbox-offline-ga.dev.js.

This renaming does not impact whether or not client pages actually communicate with Google Analytics; it's done to make it more likely that the service worker's installation can complete. (#1688)

🐛 What's Fixed?

This release fixes an issue (#1677) that several users have reported, triggered by precaching a URL that returns a 30x redirect to another URL. For instance, having '/index.html' listed in your precache manifest can trigger this issue, if your web server responds to requests for '/index.html' with a 301 redirect to the destination URL '/'. When the issue manifests itself, the final, redirect content ends up being served with an incorrect Content-Type: response header, which can in turn lead problems displaying that cached content.

If you do use 30x redirects for some of your URLs, we recommend updating to this latest release of Workbox.

In order to "clear out" the problematic content that was previously precached with an incorrect Content-Type, after updating Workbox, you can deploy a small change to URLs that you know are affected (i.e. make any change to your '/index.html' file, if that's being fulfilled with a 30x redirect).

It's also possible to force all previously cached entries to be precached again by changing the cacheId option in "generate SW" mode, or by including

workbox.core.setCacheNameDetails({precache: 'my-new-id'});

in your service worker source file in "inject manifest" mode.

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

This release contains a fix for a missing dependency entry in workbox-webpack-plugin's package.json. Thanks to @arcanis for contributing the fix in #1667!

There are no functional changes in this release.

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

Added the disable() method to workbox.navigationPreload

• workbox.navigationPreload provides an enable() method to enable navigation preload, but it did not provide a way to disable it (without invoking the underlying service worker APIs). Now developers can call workbox.navigationPreload.disable() to disable navigation preload. (#1651)

The method option can now be used for runtime caching via generateSW()

• Incorrect validation logic was preventing the method option from being used by runtime caching configuration in generateSW(). Thanks to @chrisdns, this has been fixed! (#1638)

Bug fixes and ergonomic improvements

• Using workbox.expiration.Plugin with purgeOnQuotaError set to true would result in an error. Thanks to @salmoro for discovering and fixing the issue! (#1643).
• Plugin lifecycle callbacks previously were not called with the event that triggered them, so developers writing custom plugins could not access any information about the event in those callback. Now all plugin callback are passed the event object (when available). (#1640)
• The workbox-streams package's strategy() method is exposed on the browser build of workbox.streams that gets loaded by the workbox-sw loader, but it wasn't exported by the module in a way that was accessible to module bundlers. Now it's possible to import {strategy} from workbox-streams/strategy.mjs. (#1635).

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

More customization when generating a service worker

Developers who use Workbox to generate their service worker (using the CLI, Node interface, or webpack plugin) can now take advantage of some additional options:

• Setting offlineGoogleAnalytics: true will automatically add code to initialize Workbox's offline Google Analytics support in the generated service worker.

• Both fetchOptions and matchOptions can now be used when configuring a runtimeCaching route, and those values will be passed through when constructing the corresponding Workbox caching strategy. Many thanks to @peterjosling for contributing this in #1608.

• Using a custom plugin within a runtimeCaching route is now possible, thanks to enhancements made by @tsirlucas in #1598.

Here's a snippet of Workbox's build configuration, showing off all of the new features:

{
  // ... other options ...
  offlineGoogleAnalytics: true,
  runtimeCaching: {[
    urlPattern: /abc/,
    handler: 'staleWhileRevalidate',
    options: {
      fetchOptions: {
        mode: 'no-cors',
      },
      matchOptions: {
        ignoreSearch: true,
      },
      plugins: [{
        cacheDidUpdate: async ({cacheName, request, oldResponse, newResponse}) => {
          // Do something in your custom plugin.
        },
      }],
    },
  ]},
}

Support for the PATCH method in Workbox's router

Developers who need to match HTTP PATCH requests using Workbox's router can now do so, thanks to @kevin-brotcke's change in #1618.

Note that non-GET requests can't be added to a cache, so this is most useful when used alongside a network-only strategy configured with the Workbox background sync plugin, in order to retry failed PATCH requests once the network becomes available.

workbox.core.registerQuotaErrorCallback is now publicly visible

Due to a scoping error, the workbox.core.registerQuotaErrorCallback() function was previously not exposed. This is now public, matching the documented interface. Thanks to @Tronil for pointing out this discrepancy in #1616.

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

Support for navigation preload

The new workbox-navigation-preload module provides a simple way of opting-in to navigation preload on browsers that support the feature. When run on browsers which lack navigation preload support, using the module will have no effect.

To take advantage of this new feature, you should make sure to set up a route that will match navigation requests, and uses a strategy that makes use of the response from the network, like networkFirst, staleWhileRevalidate, networkOnly, or cacheFirst.

// Enable navigation preloads.
workbox.navigationPreload.enable();

// Swap in networkOnly, cacheFirst, or staleWhileRevalidate as needed.
const strategy = workbox.strategies.networkFirst({
  cacheName: 'cached-navigations',
  plugins: [
    // Any plugins, like workbox.expiration, etc.
  ],
});

const navigationRoute = new workbox.routing.NavigationRoute(strategy, {
  // Optionally, provide a white/blacklist of RegExps to determine
  // which paths will match this route.
  // whitelist: [],
  // blacklist: [],
});

workbox.routing.registerRoute(navigationRoute);

Developers who are already handling navigations by responding with precached HTML (potentially configured with an App Shell fallback) do not need to enable navigation preload! This feature is intended to reduce navigation latency for developers who can't precache their HTML, but still want to use Workbox to handle caching of other assets on their sites.

workbox.strategies now supports using custom CacheQueryOptions

Developers who want to customize how workbox.strategies performs its internal cache lookups can now pass in a matchOptions parameter to use as the CacheQueryOptions when cache.match() is called under the hood.

// Ignore all query parameters when performing cache lookups.
const strategy = workbox.strategies.staleWhileRevalidate({
  cacheName: 'runtime-cache',
  matchOptions: {
    ignoreSearch: true,
  },
});

Many thanks to @torbs for contributing this in https://github.com/GoogleChrome/workbox/pull/1561!

🐛 What's Fixed?

• A fix for an issue that could prevent workbox.expiration.Plugin from working as intended in Microsoft Edge. Thanks to @josephliccini for contributing https://github.com/GoogleChrome/workbox/pull/1510!

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🐛 What's Fixed?

• Don't alias the exported workbox.core.registerQuotaExceededCallback symbol [#1553] (Thanks to @xe21500 and others for reporting)
• Properly set Cache-Control on CDN hosting [#1539]
• Link to workbox.setConfig() docs after calling workbox copyLibraries [#1553]

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

Cache maintenance improvements

Two new features are available to help developers deal with cache maintenance, and in particular, storage quota errors.

First, a new deleteCacheAndMetadata() method has been added to the workbox.expiration.Plugin class. This can be called manually, and it will delete all entries in the cache that the plugin is associated with, as well as clear out all metadata related to cache expiration for the plugin instance. While it's always been possible to explicitly call caches.delete(<cacheName>), that would not clear out any expiration metadata, and could lead to unexpected expiration behavior the next time the cache was recreated. (#1500)

Next, a new purgeOnQuotaError parameter can be passed in when configuring workbox.expiration.Plugin. It defaults to false, but if set to true, you can opt-in to clearing all entries in a given cache (via a call deleteCacheAndMetadata() made automatically) whenever a quota errors occurs anywhere in Workbox. This allows you to mark certain runtime caches as being "safe" for automatic cleanup, clearing up room for your web app's more critical cache storage usage. (#1505)

Opting-in to this behavior explicitly in your service worker looks like:

workbox.routing.registerRoute(
  new RegExp('/images/'), // Change to the routing criteria you need.
  workbox.strategies.cacheFirst({
    cacheName: 'images',
    plugins: [
      new workbox.expiration.Plugin({
        maxEntries: 10,
        purgeOnQuotaError: true, // Opt-in to automatic cleanup.
      }),
    ],
  })
);

When using generateSW in a build tool along with the runtimeCaching option, you can achieve something similar with the following configuration:

generateSW({
  // ...other options...
  runtimeCaching: [{
    urlPattern: new RegExp('/images/'),
    cacheName: 'images',
    handler: 'cacheFirst',
    options: {
      expiration: {
        maxEntries: 10,
        purgeOnQuotaError: true,
      },
    },
  }],
});

Automatic cache cleanup is still in its early phases, and we encourage developers who use runtime caching (especially of opaque resources, which can lead to high quota usage) to give the new functionality a try, and provide feedback.

The fetchDidFail lifecycle event is passed a new error parameter

Developers using the fetchDidFail lifecycle event to write plugins which respond to a failed network request now have access to the original underlying exception, via the error property of the callback's parameter. (#1486)

More information is available in our Custom Plugins guide.

gzip'ed CDN assets

Users of the CDN copies of the Workbox runtime libraries will now benefit from Content-Encoding: gzip support, leading to smaller initial downloads. (#1523)

🐛 What's Fixed?

• Explicitly check whether ReadableStream is functional, and trigger non-streamed fallback logic when it's not, to workaround an issue with the current Edge build and workbox-streams. (#1476)
• Improve the code that swaps 'prod' for 'dev' in copyWorkboxLibraries. The new replacement logic is more robust when your destination path includes the string 'prod'. (#1488)
• The workbox-webpack-plugin integration tests are now run against webpack v4, instead of v3. (webpack v3 still remains supported; this only affects the test suite.) (#1492)

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

A new workbox-streams module

The workbox-streams module provides an easy-to-use wrapper on top of the Streams API, allowing you to create a streaming response from a sequence of multiple sources.

The new module offers a convenience workbox.streams.strategy() method that can be used as a strategy in a workbox.routing configuration, allowing you to respond to matching requests with a stream:

const apiStrategy = workbox.strategies.staleWhileRevalidate();
const streamsStrategy = workbox.streams.strategy([
  () => caches.match('start.html'),
  () => `<p>Here's an API call, using a stale-while-revalidate strategy:</p>`,
  ({event}) => apiStrategy.makeRequest({
    event,
    request: '/api/date',
  }),
  () => caches.match('end.html'),
]);
workbox.routing.registerRoute(
  new RegExp('/index'),
  streamsStrategy
);

For more information and usage examples, please see the documentation and the live demo. (#1439)

Improved resiliency during unexpected cache misses

If a cache entry that would normally be used to fulfill a request is unexpectedly missing, workbox.routing.registerNavigationRoute() will now fall back to the network to obtain that response. Previously, this would lead to a failed navigation. (#1460)

precacheAndRoute() now accepts options in injectManifest mode

Previously, when using injectManifest mode with workbox-build or workbox-cli, the default regular expression would look for precacheAndRoute([]) inside of your swSrc file, and use that [] as the point at which to inject the manifest.

We've relaxed the default regular expression so that, in addition to supporting the previous usage, it will also work with precacheAndRoute([], {...}), where {...} are the options that you might want to pass in to configure precaching behavior. (#1459)

Changes to swSrc will trigger a new webpack dev server build

When using workbox-webpack-plugin's InjectManifest mode inside of a webpack dev server environment, making updates to the swSrc file will now trigger a fresh build. Thanks to @green-arrow for the contribution! (#1432)

🐛 What's Fixed?

• Resolved an issue with workbox.strategies.staleWhileRevalidate() and workbox.strategies.cacheFirst() in the Samsung Internet browser. (#1457)
• Moved to using the public compiler.inputFileSystem API when working with the webpack filesystem. Thanks to @DorianGrey for the contribution! (#1437)

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

workbox-webpack-plugin offers more control over paths and filenames

New precacheManifestFilename and importsDirectory options were added to the webpack plugins, giving developers more control over where their generated files are saved.

When importWorkboxFrom: 'local' and output.publicPath is configured, the output.publicPath value will be prepended to the modulePathPrefix used to determine where the Workbox libraries are dynamically loaded from. This amounts to a change in the previous behavior, but based on developer expectation, the previous behavior was considered a bug.

See #1403 for more details about the change, and the documentation for the complete list of configuration options.

New makeRequest() method added to classes under workbox.strategies

Most developers will use one of Workbox's strategies as part of a router configuration. This setup makes it easy to automatically respond to specific fetch events with a response obtained from the strategy.

However, there are situations where making a request using a strategy outside of the standard router setup could be useful. For instance, you might be implementing your own routing logic, or you might want to create a composite response that contains information from multiple smaller responses, stitched together. There are also situations where you'd normally call fetch() directly, but you'd like to take advantage of the plugin integration offered by a strategy class.

See #1408 for more details.

🐛 What's Fixed?

• Use waitUntil only when it's available (#1392) (Thanks to @beatrizdemiguelperez for reporting the underlying issue: #1386)
• Correctly identify when response does not have date header set (#1422) (Thanks to @matthewjmay for identifying the issue and contributing the fix!)
• Properly deal with null cachedResponses passed to Range plugin. (#1427)

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

🎉 What's New?

• Webpack now logs errors when using glob patterns that are probably not intended to be used (#1380)
• Webpack supports absolute swDest paths (#1370 )

🐛 What's Fixed?

• Plugins for workbox-precaching setup for install and activate events. (#1367)
• workbox-precaching had an intermittent issue where the temporary cache was dropping requests (#1368)

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/

Overview of Workbox V3

Workbox v3 has been focused on reducing the size of the library, while lowering the friction for usage. This has been accomplished thanks to a significant refactoring of the existing codebase. We believe the migration process for most users should be minimal, taking a few hours.

Developers are encouraged to view our documentation, including a migration guide for moving from either Workbox v2 or from sw-precache/sw-toolbox to Workbox v3.

Many thanks to @beatrizdemiguelperez, @raejin, @goldhand for contributing code for the v3 release, and to all the members of the community who tested and gave feedback during our alpha and beta periods.

🥅 High-level Goals for v3

Minimize the size of Workbox

The size of the Workbox libraries has been reduced. Instead of opting everyone in to a monolithic bundle, only code for the features you use will be imported at runtime.

Workbox has official CDN support

We provide a Google Cloud Storage-based CDN of the Workbox runtime libraries, making it easier to get up and running with Workbox.

Improved webpack Plugin

workbox-webpack-plugin integrates more closely with the webpack build process, allowing for a zero-config use case when you want to precache all the assets in the build pipeline.

Achieving these goals, and cleaning up some aspects of the previous interface that felt awkward or led to antipatterns, required introducing a number of breaking changes in the v3 release.

Better Debugging and Logs

The debugging and logging experience has been vastly improved. Debug logs are enabled by default whenever Workbox is used from a localhost origin and all logging and assertions are stripped from the production builds

🎉 New Functionality

workbox-build

• globFollow and globStrict added to workbox-build. This means symbolic links will be followed when searching for files and any errors discovered by glob will now throw. (#1104)

workbox-cli

• Support --injectManifest in the workbox-cli wizard. (#1171)

workbox-precaching

• workbox-precaching supports two new configuration options, cleanUrls and urlManipulation. By default cleanUrls is true and will append .html to a reqest when looking for a precache hit (i.e. /about will check for /about.html). urlManipulation can be a function enabling you to express a mapping between the server-side URL and the underlying local file. (#1154)

• If a precached request is not in the cache, we fallback to the network. (#1302)

• Precaching will store requests in a temporary cache on install and copy these requests to final cache during the activate step. (#1316)

• The precaching IndexedDB name is now derived from the cache name - allowing multiple precaches on a single origin. (#1346)

workbox-strategies

• Fallback to the network response whena network timeout is reached and there is no cache hitfor the network-first strategy. (#1301)
• Support for configuring fetch options in a strategy. (#1340)

workbox-webpack-plugin

• Adds support for webpack v4, while retaining support for webpack v3. (#1275)

• workbox-webpack-plugin now supports {test, include, exclude}-style filtering, providing an additional way of controlling which assets are included in the precache manifest. By default, assets matching /\.map$/ or /^manifest\.js(?:on)$/ are excluded. (#1149)

⚠️ Breaking Changes

Build Configuration

The following changes affect the behavior of all of our build tools (workbox-build, workbox-cli, workbox-webpack-plugin), which share a common set of configuration options.

• The 'fastest' handler name was previously valid, and treated as an alias for 'staleWhileRevalidate', when configuring runtimeCaching. It's no longer valid, and developers should switch to using 'staleWhileRevalidate' directly. (https://github.com/GoogleChrome/workbox/issues/915)

• Several runtimeCaching.options property names have been updated, and additional parameter validation is in place that will cause a build to fail if an invalid configuration is used. See the documentation for runtimeCaching for a list of currently supported options. (https://github.com/GoogleChrome/workbox/issues/1096)

• A new importWorkboxFrom option can be used to determine where the Workbox libraries are read from: the CDN, locally, or from a custom bundle (when using webpack).

workbox-background-sync

• There are significant changes to the API surface in v3. Developers should consult the documentation for current guidance. (https://github.com/GoogleChrome/workbox/issues/868)

• The maxRetentionTime configuration option is now interpreted as a number of minutes, rather than milliseconds. (#1268)

• The tag name is now used when responding to a sync event. (#1280)

workbox-build

• The default destination of a service worker for the CLI has changed from 'build/' to the location of the globDirectory (i.e. the directory searched for files to precache). (#1105)

• The getFileManifestEntries() function has been renamed to getManifest(), and the promise returned now includes additional information about the URLs which are precached.

• The generateFileManifest() function has been removed. Developers are encouraged to call getManifest() instead, and use its response to write data to disk in the appropriate format.

workbox-cache-expiration

• The plugin API has stayed the same, however there are significant API changes impacting developers who use it as a standalone class. Consult the documentation for the updated API surface. (https://github.com/GoogleChrome/workbox/issues/920)

• workbox-cache-expiration now throws an error if you attempt to expire entries on the default runtime cache (i.e. the shared cache used by all strategies by default). (#1079)

workbox-cli

• The set of command line options, and the way of reading in stored configuration, have all changed. Developers should consult the documentation or run the CLI with the --help flag for guidance. (https://github.com/GoogleChrome/workbox/issues/865)

• Support for the workbox-cli alias for the binary script has been removed. The binary can now only be accessed as workbox. (https://github.com/GoogleChrome/workbox/issues/730)

workbox-google-analytics

• While the API surface has not changed, the underlying implementation was updated to use the workbox-background-sync library, and therefore rely on the Background Sync API. (https://github.com/GoogleChrome/workbox/issues/244)

workbox-precaching

• The precache() method previously performed both the cache modifications and set up routing to serve cached entries. Now, precache() only modifies cache entries, and a new method, addRoute(), has been exposed to register a route to serve those cached responses. Developers who want the previous, two-in-one functionality can switch to calling precacheAndRoute(). This enables more developer flexibility. (https://github.com/GoogleChrome/workbox/issues/886).

• workbox-broadcast-update will no longer be automatically configured to announce cache updates for precached assets. To get this behavior, you can add the plugin manually. (https://github.com/GoogleChrome/workbox/issues/1073)

workbox-routing

• The Router will now evaluate Routes in a first-registered-wins order. This is the opposite order of Route evaluation that was used in v2, where the last-registered Route would be given precedence. (https://github.com/GoogleChrome/workbox/issues/845)

• The ExpressRoute class, and support for "Express-style" wildcards have been removed. This reduces the size of workbox-routing considerably. Strings used as the first parameter to workbox.routing.registerRoute() will now be treated as exact matches. Wildcard or partial matches should be handled by RegExps—using any RegExp that matches against part or all of the request URL can trigger a route. (https://github.com/GoogleChrome/workbox/issues/1012)

• The addFetchListener() helper method of the Router class has been removed. Developers can either add their own fetch handler explicitly, or use the interface provided by workbox.routing, which will implicitly create a fetch handler for them. (https://github.com/GoogleChrome/workbox/issues/914)

• The registerRoutes() and unregisterRoutes() methods were removed. The versions of those methods that operate on a single Route were not changed, and developers who need to register or unregister multiple routes at once should make a series of calls to registerRoute() or unregisterRoute() instead. (https://github.com/GoogleChrome/workbox/issues/856)

workbox-strategies (formerly know as workbox-runtime-caching)

• The workbox-runtime-caching module is now officially known as workbox-strategies, and has been published on npm under its new name. (https://github.com/GoogleChrome/workbox/issues/1045)

• The syntax for specifying plugins when configuring a strategy has changed. Each plugin needs to be explicitly listed in the plugins property of the strategy's configuration. (https://github.com/GoogleChrome/workbox/issues/1071)

• Defining a strategy that applies to the default cache name and which uses cache expiration is no longer supported. When configuring cache expiration, you must also configure a specific cache name. (https://github.com/GoogleChrome/workbox/issues/1014)

• The cacheWillMatch lifecycle method has been renamed to cachedResponseWillBeUsed. This should not be a visible change for developers unless they wrote their own plugins that reacted tocacheWillMatch. (https://github.com/GoogleChrome/workbox/issues/713)

workbox-sw

• The handleFetch option has been removed. (https://github.com/GoogleChrome/workbox/issues/1002)

• skipWaiting and clientsClaim are no longer options passed to the WorkboxSW constructor. Instead, they have been changed to methods of the same name that could be called on the workbox namespace. (https://github.com/GoogleChrome/workbox/issues/853)

workbox-webpack-plugin

• The plugin has been substantially rewritten, and in many cases, can be used in a "zero-configuration" mode. Consult the documentation for the updated API surface. (https://github.com/GoogleChrome/workbox/issues/696)

🎉 What's New?

• Attempting to cache a POST request will no throw a useful WorkboxError (#1336)
• Adding support to configure fetch options in a Strategy (#1340)

🐛 What's Fixed?

• Fixes BroadcastChannel on Safari Tech Preview where it's not supported. (#1304)
• Fixes broadcastUpdate in workbox-build config (#1334)
• Precaching to a temp cache in install and moving to final cache during activate step (#1316)
• Precaching cache name is now defined from the cache name - allowing multiple precaching (#1346)

📖 Learn More

Check out our docs @ developers.google.com/web/tools/workbox/next/

🎉 What's New?

• Webpack V4 (#1275 )
• [BREAKING CHANGE] Using BG Sync tag name when responding to a sync event (#1280)
• [BREAKING CHANGE] Use broadcastUpdate option instead of broadcastCacheUpdate (#1292)
• Using same-origin to precache URLS (#1293)
• Support for importWorkboxFrom: 'local' in the injectManifest Webpack Plugin (#1290)
• If a precached request is not in the cache, we fallback to the network (#1302)
• Add a warning if the cache-control header for the service worker is not set to no-cache or max-age=0 (#1317)
• Logs have been added to background-sync to aid development and debugging (#1323)
• New non-fatal warnings in workbox-build (#1325)

🐛 What's Fixed?

• import scripts including multiple precache manifests. (#1267) H/T @raejin for fix
• Fallback to network response when using a timeout but nothing is in the cache (#1301)
• Fixed logging in Safari Tech Preview (#1310)
• addRequest in background-sync now asserts you are passing in a Request object (#1305)
• google-analytics needed some fixes for replaying requests (#1319)
• Fixed importScripts in workbox-build (#1327)

The first beta release of Workbox v3 includes additional integration tests and demos, as well as the following developer-visible changes from the previous alpha release.

🎉 What's New?

• [BREAKING CHANGE] The background sync module's maxRetentionTime setting is now interpreted as a number of minutes, rather than milliseconds (#1268)

🐛 What's Fixed?

• Honor publicPath when determining the precache manifest URL. (#1233)
• Show the --help message when there are no params passed to workbox-cli. (#1242)
• Tweak wording for root of web app question. (#1243)
• Refactor the way CLI parameters are processed by workbox-cli. (#1246)
• Ignore .map when suggesting extensions to precache in the workbox-cli wizard. (#1255)
• Make workbox sw chunk prefix with public path (#1265) (Thanks to @raejin for their contribution!)

The latest alpha release of Workbox includes some project health improvements, as well as the following developer-visible changes from the previous alpha release.

🎉 What's New?

• #1171 Support --injectManifest in the workbox-cli wizard.

🐛 What's Fixed?

• #1173 Properly deal with webpack's publicPath + importWorkboxFrom: 'local'
• #1181 Don't copy the same workbox-sw.js(.map) files twice
• #1203 Tweak async/await usage to avoid a bug in the final prod bundle.
• #1184 Switching to a db name instead of just a store name
• #1216 Call new on the corresponding Plugin class.

🎉 What's New?

• #1138 Plugins can now be added to workbox-precaching; this is useful for adding plugins like workbox-broadcast-cache-update.
• #1149 workbox-webpack-plugin now supports {test, include, exclude}-style filtering, providing an additional way of controlling which assets are included in the precache manifest. By default, assets matching /\.map$/ or /^manifest\.js(?:on)$/ are excluded.
• #1154 workbox-precaching supports two new configuration options, cleanUrls and urlManipulation. By default cleanUrls is true and will check the precache for a with .html on the end (i.e. /about will check for /about.html. urlManipulation can be a function enabling you to express a mapping between the server-side URL and the underlying local file.

🐛 What's Fixed?

• #1130 A cleaner service worker template.
• #1127, #1128, #1126, #1133, #1132 Various improvements to the test suite.
• #1139 Fix for an IDB bug, which could prevent v2 to v3 migrations from succeeding.
• #1155 Fix for a bug that could cause workbox-background-sync to enter a loop of repeated registrations.
• #1168 A fix for broken expiration.

⚠️ Breaking Changes

• #1137 The importWorkboxFromCDN boolean option, which was supported in previous v3 alpha releases of workbox-build, has been replaced by importWorkboxFrom. Valid values for importWorkboxFrom are 'cdn', 'local', null, or (when used from the workbox-webpack-plugin) the name of a webpack chunk.
• #1143 The workbox-webpack-plugin module now exposes two top-level webpack plugins, named GenerateSW and InjectManifest. Developers need to explicitly use one of these two plugins, depending on whether they want to create a new service worker file each time they run their build (GenerateSW) or whether they want to use an existing service worker file but inject updated precache manifest information each time they build (InjectManifest).
• #1160 The valid runtimeCaching options have been updated, representing a break from the older syntax supported by sw-precache. The following example contains the full set of currently supported options:

runtimeCaching: [{
  urlPattern: /api/,
  handler: 'networkFirst',
  options: {
    networkTimeoutSeconds: 10,
    cacheName: 'my-api-cache',
    expiration: {
      maxEntries: 5,
      maxAgeSeconds: 60,
    },
    cacheableResponse: {
      statuses: [0, 200],
      headers: {'x-test': 'true'},
    },
    broadcastUpdate: {
      channelName: 'my-update-channel',
    },
    plugins: [
      {cacheDidUpdate: () => /* custom plugin code */}
    ],
  },
}]

🎉 What's New?

• #1138 Plugins can now be added to workbox-precaching; this is useful for adding plugins like workbox-broadcast-cache-update.
• #1149 workbox-webpack-plugin now supports {test, include, exclude}-style filtering, providing an additional way of controlling which assets are included in the precache manifest. By default, assets matching /\.map$/ or /^manifest\.js(?:on)$/ are excluded.
• #1154 workbox-precaching supports two new configuration options, cleanUrls and urlManipulation. By default cleanUrls is true and will check the precache for a with .html on the end (i.e. /about will check for /about.html. urlManipulation can be a function enabling you to express a mapping between the server-side URL and the underlying local file.

🐛 What's Fixed?

• #1130 A cleaner service worker template.
• #1127, #1128, #1126, #1133, #1132 Various improvements to the test suite.
• #1139 Fix for an IDB bug, which could prevent v2 to v3 migrations from succeeding.
• #1155 Fix for a bug that could cause workbox-background-sync to enter a loop of repeated registrations.

⚠️ Breaking Changes

• #1137 The importWorkboxFromCDN boolean option, which was supported in previous v3 alpha releases of workbox-build, has been replaced by importWorkboxFrom. Valid values for importWorkboxFrom are 'cdn', 'local', null, or (when used from the workbox-webpack-plugin) the name of a webpack chunk.
• #1143 The workbox-webpack-plugin module now exposes two top-level webpack plugins, named GenerateSW and InjectManifest. Developers need to explicitly use one of these two plugins, depending on whether they want to create a new service worker file each time they run their build (GenerateSW) or whether they want to use an existing service worker file but inject updated precache manifest information each time they build (InjectManifest).
• #1160 The valid runtimeCaching options have been updated, representing a break from the older syntax supported by sw-precache. The following example contains the full set of currently supported options:

runtimeCaching: [{
  urlPattern: /api/,
  handler: 'networkFirst',
  options: {
    networkTimeoutSeconds: 10,
    cacheName: 'my-api-cache',
    expiration: {
      maxEntries: 5,
      maxAgeSeconds: 60,
    },
    cacheableResponse: {
      statuses: [0, 200],
      headers: {'x-test': 'true'},
    },
    broadcastUpdate: {
      channelName: 'my-update-channel',
    },
    plugins: [
      {cacheDidUpdate: () => /* custom plugin code */}
    ],
  },
}]

🎉 Whats New

• #1108 Added workbox-range-requests to v3
• #1104 globFollow and globStrict added to workbox-build. This means symbolic links will be followed when searching for files and any errors discovered by glob will now throw.

🐛 Whats Fixed

• #1111 Fixed a bug in precaching where indexedDB wasn't updating correctly
• #1112 Fixes updates to precaching indexedDB schema when upgrading from V2 to V3
• #1116 Fixes a grouping issue in logs if precaching fails.

⚠️ Breaking Changes

• #1105 The default destination of a service worker for the CLI has changed from 'build/' to the location of the globDirectory (i.e. the directory searched for files to precache).
• #1079 workbox-cache-expiration now throws an error if you attempt to use it on the runtime cache (i.e. the shared cache used by all strategies by default)

Overview of Workbox V3

Workbox's v3 release represents a significant refactoring of the existing codebase.

🎉 Whats New

Minimize the size of Workbox

The amount of service worker runtime code that's downloaded and executed has been reduced. Instead of opting everyone in to a monolithic bundle, only code for the specific features that you're using will be imported at runtime.

Workbox has a CDN

We provide a fully supported, Google Cloud Storage-based CDN hosting as the canonical option for accessing the Workbox runtime libraries, making it easier to get up and running with Workbox.

Better Debugging and Logs

The debugging and logging experience has been vastly improved. Debug logs are enabled by default whenever Workbox is used from a localhost origin and all logging and assertions are stripped from the production builds

Improved webpack Plugin

workbox-webpack-plugin integrates more closely with the webpack build process, allowing for a zero-config use case when you want to precache all the assets in the build pipeline.

Achieving these goals, and cleaning up some aspects of the previous interface that felt awkward or led to antipatterns, required introducing a number of breaking changes in the v3 release.

⚠️ Breaking Changes

Build Configuration

The following changes affect the behavior of all of our build tools (workbox-build, workbox-cli, workbox-webpack-plugin), which share a common set of configuration options.

• The 'fastest' handler name was previously valid, and treated as an alias for 'staleWhileRevalidate', when configuring runtimeCaching. It's no longer valid, and developers should switch to using 'staleWhileRevalidate' directly. (https://github.com/GoogleChrome/workbox/issues/915)

• Several runtimeCaching.options property names have been updated, and additional parameter validation is in place that will cause a build to fail if an invalid configuration is used. See the documentation for runtimeCaching for a list of currently supported options. (https://github.com/GoogleChrome/workbox/issues/1096).

workbox-background-sync

• There are significant changes to the API surface in v3. Developers should consult the documentation for current guidance. (https://github.com/GoogleChrome/workbox/issues/868)

workbox-cache-expiration

• The plugin API has stayed the same, however there are significant API changes impacting developers who use it as a standalone class. Consult the documentation for the updated API surface. (https://github.com/GoogleChrome/workbox/issues/920)

workbox-cli

• The set of command line options, and the way of reading in stored configuration, have all changed. Developers should consult the documentation or run the CLI with the --help flag for guidance. (https://github.com/GoogleChrome/workbox/issues/865)

• Support for the workbox-cli alias for the binary script has been removed. The binary can now only be accessed as workbox. (https://github.com/GoogleChrome/workbox/issues/730)

workbox-google-analytics

• While the API surface has not changed, the underlying implementation was updated to use the workbox-background-sync library, and therefore rely on the Background Sync API. (https://github.com/GoogleChrome/workbox/issues/244)

workbox-precaching

• The precache() method previously performed both the cache modifications and set up routing to serve cached entries. Now, precache() only modifies cache entries, and a new method, addRoute(), has been exposed to register a route to serve those cached responses. Developers who want the previous, two-in-one functionality can switch to calling precacheAndRoute(). This enables more developer flexibility. (https://github.com/GoogleChrome/workbox/issues/886).

• workbox-broadcast-update will no longer be automatically configured to announce cache updates for precached assets. To get this behavior, you can add the plugin manually. (https://github.com/GoogleChrome/workbox/issues/1073)

workbox-routing

• The Router will now evaluate Routes in a first-registered-wins order. This is the opposite order of Route evaluation that was used in v2, where the last-registered Route would be given precedence. (https://github.com/GoogleChrome/workbox/issues/845)

• The ExpressRoute class, and support for "Express-style" wildcards have been removed. This reduces the size of workbox-routing considerably. Strings used as the first parameter to workbox.routing.registerRoute() will now be treated as exact matches. Wildcard or partial matches should be handled by RegExps—using any RegExp that matches against part or all of the request URL can trigger a route. (https://github.com/GoogleChrome/workbox/issues/1012)

• The addFetchListener() helper method of the Router class has been removed. Developers can either add their own fetch handler explicitly, or use the interface provided by workbox.routing, which will implicitly create a fetch handler for them. (https://github.com/GoogleChrome/workbox/issues/914)

• The registerRoutes() and unregisterRoutes() methods were removed. The versions of those methods that operate on a single Route were not changed, and developers who need to register or unregister multiple routes at once should make a series of calls to registerRoute() or unregisterRoute() instead. (https://github.com/GoogleChrome/workbox/issues/856)

workbox-strategies (formerly know as workbox-runtime-caching)

• The workbox-runtime-caching module is now officially known as workbox-strategies, and has been published on npm under its new name. (https://github.com/GoogleChrome/workbox/issues/1045)

• The syntax for specifying plugins when configuring a strategy has changed. Each plugin needs to be explicitly listed in the plugins property of the strategy's configuration. (https://github.com/GoogleChrome/workbox/issues/1071)

• Defining a strategy that applies to the default cache name and which uses cache expiration is no longer supported. When configuring cache expiration, you must also configure a specific cache name. (https://github.com/GoogleChrome/workbox/issues/1014)

• The cacheWillMatch lifecycle method has been renamed to cachedResponseWillBeUsed. This should not be a visible change for developers unless they wrote their own plugins that reacted tocacheWillMatch. (https://github.com/GoogleChrome/workbox/issues/713)

workbox-sw

• The handleFetch option has been removed. (https://github.com/GoogleChrome/workbox/issues/1002)

• skipWaiting and clientsClaim are no longer options passed to the WorkboxSW constructor. Instead, they have been changed to methods of the same name that could be called on a WorkboxSW instance. (https://github.com/GoogleChrome/workbox/issues/853)

workbox-webpack-plugin

• The plugin has been substantially rewritten, and in many cases, can be used in a "zero-configuration" mode. Consult the documentation for the updated API surface. (https://github.com/GoogleChrome/workbox/issues/696)

What's new?

The 2.1.3 release contains a few changes to the workbox-background-sync and workbox-broadcast-cache-update modules to ensure that they will not attempt to use the Broadcast Channel API on a browsers that lacks support for it.

Safari is one such browser.

Notable PRs

• Gracefully no-op when BroadcastChannel doesn't exist (#1291)

What's new?

The 2.0.3 release adds babel-preset-env-based transpilation into the build process for our browser libraries, currently targeted at compatibility with Chrome 51 and above. Following this change, the Workbox libraries should work within Samsung Browser 5 (which shares code with Chrome 51), while maintaining its existing compatibility with "evergreen" browsers.

Bug Fixes

• Using async, await makes workbox without further transpilation break on Samsung Internet (Thanks to @HenrikJoreteg for reporting!)

This release adds support for stable versions of Samsung Browser. Workbox was previously not transpiling async/await functions but now uses babel-preset-env to support versions of Chrome >= 51.

What's new?

The 2.0.1 release contains two bug fixes in the public interfaces.

Bug Fixes

workbox-build

• Fix backslashes replacement. (Thanks, @XhmikosR!)

workbox-sw

• Ensure that ignoreUrlParametersMatching works with directoryIndex

What's new?

The v2.0.0 introduces a few breaking changes to interfaces, along with bug fixes and new functionality. Please read carefully before upgrading!

Note that all Workbox packages have been tagged with the 2.0.0 version number on npm, regardless of whether they have breaking changes or not.

Breaking changes

workbox-cli

• Move towards using 'workbox' over 'workbox-cli'. The workbox-cli alias for the command line interface is now deprecated, in favor of the preferred workbox alias. Using workbox-cli will log a warning message, and it will be removed as an alias in a future release. Developers are encouraged to switch to using workbox now.

workbox-routing

• No longer register a fetch handler for each Router by default We've made registering a fetch handler optional, allowing developers who want more control to use the Router class from inside any fetch handler. Developers who are using the workbox-routing module directly can call router.addFetchListener() to mimic the previous behavior.

workbox-runtime-caching

• Rename cacheWillMatch to cachedResponseWillBeUsed Developers who have implemented their own Workbox plugins that respond to cacheWillMatch lifecycle events should rename the method they expose to cachedResponseWillBeUsed. Developers using the pre-made plugins do not need to change anything.
• Adds JSDocs for the lifecycle methods, and awaits the return of each. The underlying RequestWrapper object that triggers request lifecycle methods will now always await the methods' return values. No changes should be necessary unless you've implemented your own plugin which returns a Promise and you do not want the RequestWrapper to delay while waiting for it to resolve.

New features

workbox-range-requests

• New library to support Range requests This allows Workbox to honor the Range: request header when fulfilling requests for cached resources. This comes up often when playing back cached media content.

Other changes

workbox-build

• Improved the workbox-build JSDoc

workbox-webpack-plugin

• adding manifest transform for webpack public path

What's new?

The v1.3.0 release contains a few bug fixes for the workbox-build and workbox-sw projects.

It also includes some internal testing changes.

Note that packages that have not changed since the last release will not be tagged with a new version number on npm.

workbox-build

• fixed: bug that cauases passed in manifestTransforms not to run (thanks to @HenrikJoreteg)

workbox-routing

• Adds JSDocs for the handleFetch parameter

workbox-sw

• Fix for multiple cacheId prefixes in the precache handler (thanks to @HenrikJoreteg for reporting)
• Add all of workbox-sw's devDependencies to fix Lerna's versioning.

What's new?

The v1.2.0 release contains a number of smaller changes and bug fixes across several packages; note that packages that have not changed since the last release will not have a 1.2.0 version published on npm.

workbox-background-sync

• fixing queue initialization bug

workbox-build

• typo: fix small typo (thanks to @markgoho)
• Copies sourcemap over with source files
• Adding defaults to workbox-build
• Add use strict to generate-sw for Node 4 support (thanks to @MaxLeiter)
• Adds support for manifestTransforms

workbox-cache-expiration

• Fixes a bug with cacheFirst handler + maxAgeSeconds + CORS request (h/t to @pbakaus for reporting)

workbox-precaching

• Adding some logging for the precache details

What's new?

The v1.1.0 release contains a number of smaller changes and bug fixes across multiple packages.

workbox-sw

• You can now unregister previously registered routes using workbox-sw: https://github.com/GoogleChrome/workbox/pull/632
• The URL's query parameters will be included when matching NavigationRoute's white/blacklist: https://github.com/GoogleChrome/workbox/pull/637
• Makes it easier to register custom Route instances when using workbox-sw: https://github.com/GoogleChrome/workbox/pull/639
• Support for using non-GET HTTP verbs in workbox-sw's routes: https://github.com/GoogleChrome/workbox/pull/662

workbox-build / workbox-cli / workbox-webpack-plugin

• Ignore node_modules by default when using workbox-build: https://github.com/GoogleChrome/workbox/pull/609
• Improvements to workbox-cli when run from a directory that doesn't have subdirectories, or has hidden directories: https://github.com/GoogleChrome/workbox/pull/614 and https://github.com/GoogleChrome/workbox/pull/616
• workbox-build no longer unconditionally prepends a leading '/': https://github.com/GoogleChrome/workbox/issues/560

workbox-background-sync

• Fixes to replaying requests in workbox-background-sync: https://github.com/GoogleChrome/workbox/pull/601
• Added additional callbacks to workbox-background-sync: https://github.com/GoogleChrome/workbox/pull/666

Common

• Smaller dev bundles: https://github.com/GoogleChrome/workbox/pull/594
• Hashes present in request URLs will be stripped: https://github.com/GoogleChrome/workbox/pull/633