🎉 What's New?
The latest beta release of Workbox v5 includes the following developer-visible changes, in addition to all the changes from the previous pre-release.
workbox-broadcast-update
A generatePayload()
configuration option has been added to the BroadcastCacheUpdate
and BroadcastUpdatePlugin
classes that allows developers to customize the message that gets sent to the window when a cached response has been udpated.
The generatePayload()
function is called with the same arguments as the cacheDidUpdate()
plugin callback, and its return value will be used as the message payload. Here's an example that adds the Last-Modified
header value of the updated response to the payload:
new BroadcastUpdatePlugin({
generatePayload({request, newResponse}) {
return {
url: request.url,
lastModified: newResponse.headers.get('Last-Modified'),
};
},
});
workbox-core
A copyResponse()
method has been added that can be used to clone a response and modify its headers
, status
, or statusText
. [#2193]
Here's an example that adds a custom header to indicate that a response came from the cache (and not the network):
const newResponse = copyResponse(oldResponse, (responseInit) => {
responseInit.headers.set('X-Cache', 'hit');
return responseInit;
});
workbox-precaching
If workbox-precaching
needs to bypass the HTTP cache when requesting a URL, it will now set cache: 'reload'
on the outgoing Request
, which in turns sets the appropriate Cache-Control
headers. [#2176]
Previously, bypassing the HTTP cache was done by adding in a __WB_REVISION=...
URL query parameter to the outgoing network request, meaning that backend web servers would see requests for URLs containing those query parameters. With this change in place, requests for URLs with __WB_REVISION=...
should no longer be seen in HTTP server logs.
Please note that this change only applies to outgoing HTTP requests used to populate the precache, and does not apply to cache keys. The keys for some entries created by workbox-precaching
still include the __WB_REVISION=...
parameter, and it's still a best practice to call getCacheKeyForURL()
to determine the actual cache key, including the __WB_REVISION
parameter, if you need to access precached entries using the Cache Storage API directly.
All build tools
Any manifestTransform
callbacks are now treated as being async
, and each callback will be await
-ed by the build tools. If you supply multiple transforms, they will still be run sequentially, in the same order. [#2195]
This should not be a breaking change, as you can continue providing non-async
callback functions, and they will still work as before.
workbox-build and workbox-cli
As part of a general refactoring of how the options passed to all of our build tools are parsed [#2191], using precaching in the generateSW
mode of workbox-build
and workbox-cli
is no longer mandatory. You can now use the runtimeCaching
options without configuring the glob
-related options, and your generated service worker will just contain the corresponding runtime caching routes.
If you don't configure the glob
-related options and you don't use runtimeCaching
, that will lead to a build error.
⚠️ Breaking Changes
workbox-broadcast-update
The workbox-broadcast-update
package no longer uses BroadcastChannel
, even in cases when the browser supports it. Instead it uses postMessage()
to message window clients. [#2184]
This change was made because postMessage()
messages are automatically buffered by the window to handle cases where the service worker sends a message before the code running on the window is ready to receive it. BroadcastChannel
has no such buffering, and thus you're more likely to miss message when using it.
If you're currently listening for BroadcastChannel
messages in your code running on the window, you'll now need to listen for message
events on the ServiceWorkerContainer
:
navigator.serviceWorker.addEventListener('message', (event) => {
console.log(event.data);
})
Note: workbox-window
users should not need to make any changes, as its internal logic has been updated to listen for postMessage()
calls.
Plugin classes
- All
Plugin
classes have been renamed to be package-specific, e.g.ExpirationPlugin
,CacheableResponsePlugin
, etc. If you're using one of the Workbox build tools ingenerateSW
mode to create your service worker, this change will be handled for you automatically. If you use one of the plugins in a manually created service worker, you'll need to explicitly change instances ofPlugin
to the correct revised class name. [#2187]
🐛 What's Fixed?
workbox-routing
- A
RouteHandlerObject
type has been added to fix TypeScript typing issue when using strategy classes as route handlers. [#2183]
workbox-webpack-plugin
importScriptsViaChunks
will only callimportScripts()
on assets in that chunk which have a.js
extension. [#2164]- The
GenerateSW
mode will now work properly when there are multiple compilations (via, e.g.,webpack-dev-server
). [#2167] - The
json-stable-stringify
dependency has been replaced byfast-json-stable-stringify
. [#2163] - When using multiple instances of
workbox-webpack-plugin
in the same compilation, assets created by those other instances will now be excluded from each others' precache manifest. [#2182]
Thanks
Special thanks to @kaykayehnn for their bug reports and contributions that went into this release.