Workbox v3.0.0-alpha.2
Pre-releaseOverview 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 configuringruntimeCaching
. It's no longer valid, and developers should switch to using'staleWhileRevalidate'
directly. (#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 forruntimeCaching
for a list of currently supported options. (#1096).
workbox-background-sync
- There are significant changes to the API surface in v3. Developers should consult the documentation for current guidance. (#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. (#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. (#865) -
Support for the
workbox-cli
alias for the binary script has been removed. The binary can now only be accessed asworkbox
. (#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. (#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 callingprecacheAndRoute()
. This enables more developer flexibility. (#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. (#1073)
workbox-routing
-
The
Router
will now evaluateRoute
s in a first-registered-wins order. This is the opposite order ofRoute
evaluation that was used in v2, where the last-registeredRoute
would be given precedence. (#845) -
The
ExpressRoute
class, and support for "Express-style" wildcards have been removed. This reduces the size ofworkbox-routing
considerably. Strings used as the first parameter toworkbox.routing.registerRoute()
will now be treated as exact matches. Wildcard or partial matches should be handled byRegExp
s—using anyRegExp
that matches against part or all of the request URL can trigger a route. (#1012) -
The
addFetchListener()
helper method of theRouter
class has been removed. Developers can either add their ownfetch
handler explicitly, or use the interface provided byworkbox.routing
, which will implicitly create afetch
handler for them. (#914) -
The
registerRoutes()
andunregisterRoutes()
methods were removed. The versions of those methods that operate on a singleRoute
were not changed, and developers who need to register or unregister multiple routes at once should make a series of calls toregisterRoute()
orunregisterRoute()
instead. (#856)
workbox-strategies (formerly know as workbox-runtime-caching)
-
The
workbox-runtime-caching
module is now officially known asworkbox-strategies
, and has been published onnpm
under its new name. (#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. (#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. (#1014)
-
The
cacheWillMatch
lifecycle method has been renamed tocachedResponseWillBeUsed
. This should not be a visible change for developers unless they wrote their own plugins that reacted tocacheWillMatch
. (#713)
workbox-sw
-
The
handleFetch
option has been removed. (#1002) -
skipWaiting
andclientsClaim
are no longer options passed to theWorkboxSW
constructor. Instead, they have been changed to methods of the same name that could be called on aWorkboxSW
instance. (#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. (#696)