-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(deps): update workbox monorepo to v7 (major) #26
Open
renovate
wants to merge
1
commit into
master
Choose a base branch
from
renovate/major-workbox-monorepo
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7b0836c
to
65d96b3
Compare
65d96b3
to
6d7b9ae
Compare
6d7b9ae
to
572fb01
Compare
572fb01
to
0bf5f83
Compare
0bf5f83
to
f31a030
Compare
f31a030
to
1b010cd
Compare
1b010cd
to
376ae4a
Compare
376ae4a
to
66e6885
Compare
66e6885
to
e79bf13
Compare
e79bf13
to
559b79f
Compare
559b79f
to
b6bff83
Compare
b6bff83
to
a348848
Compare
f1a7238
to
010c37f
Compare
010c37f
to
2db4ff5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
5.1.4
->7.1.0
Release Notes
googlechrome/workbox (workbox-background-sync)
v7.1.0
Compare Source
What's Changed ✏️
Thanks 🙏
Full Changelog: GoogleChrome/workbox@v7.0.0...v7.1.0
v7.0.0
: Workbox v7.0.0Compare Source
v6.6.1
Compare Source
v6.6.0
Compare Source
v6.5.4
Compare Source
What's New 👀
config
property [#3056]workbox-precaching
during a fall back to the network, if the request'smode
isno-cors
,integrity
will not be used and the cache entry will not be repaired. [#3099]What's fixed 🐛
Misc 🤹
idb
andselenium-assitant
versionsThank yous 🌿
Full Changelog: GoogleChrome/workbox@v6.5.3...v6.5.4
v6.5.3
Compare Source
v6.5.2
: Workbox v6.5.2Compare Source
Workbox v6.5.2 includes a number of improvements to the TypeScript documentation and exported types, which should in turn improve the generated documentation.
A full changelog is available at GoogleChrome/workbox@v6.5.1...v6.5.2
v6.5.1
: Workbox v6.5.1Compare Source
The Workbox v6.5.1 release includes a few changes related to our TypeScript interfaces and documentation.
A full changelog is available at GoogleChrome/workbox@v6.5.0...v6.5.1
What's New
@example
s of using our build tools have been added to the TSDocs forworkbox-build
andworkbox-webpack-plugin
. [#3038]generateSW()
,injectManifest()
, andgetManifest()
methods inworkbox-build
has been updated fromunknown
to an appropriate actual type specific to each method. This should lead to better TSDoc generation and type inferences for developers. As this takes what was previously only a runtime check and moves it to a compile-time check, we believe that it should be functionally equivalent to prior releases, but if you run into problems, please let us know by opening an issue. [#3037]What's Fixed
default
export toworkbox-webpack-plugin
. [#3036]v6.5.0
: Workbox v6.5.0Compare Source
The Workbox v6.5.0 release includes a number of smaller fixes, as well as a major rewrite of the
workbox-webpack-plugin
to TypeScript.A full changelog is available at GoogleChrome/workbox@v6.4.2...v6.5.0
What's New
workbox-webpack-plugin
has been rewritten in TypeScript, and has public TypeScript definitions for its interfaces published as part of this release. We do not anticipate any changes in the underlying functionality as part of this rewrite. [#2882]forceSyncFallback
parameter has been added toworkbox-background-sync
, without changing the default behavior. WhenforceSyncFallback
is explicitly set totrue
,workbox-background-sync
will always attempt to replay queued requests when the service worker starts up and never rely on thesync
event listener. Most developers will not need this behavior, but it can be useful when targeting environments that have a non-functional Background Sync implementation, like some Electron runtimes. [#3020]What's Fixed
workbox-streams
. [#3001]workbox-background-sync
which could lead to errors when run through with certain aggressive minifiers. [#3012]waitUntil()
was added to theStaleWhileRevalidate
strategy, ensuring that it works properly with navigation preload responses. [#3015]source-map-url
package. [#3031]New Contributors
Thank you to @roikoren755 for their contributions to the
workbox-webpack-plugin
TypeScript migration!v6.4.2
: Workbox v6.4.2Compare Source
The Workbox v6.4.2 release fixes a few issues:
What's Changed
@apideck/better-ajv-errors
to ^0.3.1 by @wopian in https://github.com/GoogleChrome/workbox/pull/2988ExpirationPlugin
docs by @mungojam in https://github.com/GoogleChrome/workbox/pull/2987workbox wizard --injectManifest
by @jeffposnick in https://github.com/GoogleChrome/workbox/pull/2992New Contributors
Full Changelog: GoogleChrome/workbox@v6.4.1...v6.4.2
v6.4.1
: Workbox v6.4.1Compare Source
The Workbox v6.4.1 release fixes a few issues:
🐛 What's Fixed?
workbox-build
@apideck/better-ajv-errors
has been updated, which in turn addresses a security issue in one of its dependencies. [#2977]worbox-navigation-preload
preloadResponse
was incorrect, and has been fixed to reflect the previous definition that used to be provided by the TypeScript standard library. [#2975]worbox-strategies
request.url
into account inStrategyHandler.getCacheKey()
. This ensures if a custom strategy overrides theStrategy._handle()
method and performs multiple cache operations on different URLs, the cache key is properly calculated for each distinct URL. [#2973]v6.4.0
: Workbox v6.4.0Compare Source
Workbox v6.4.0 includes:
🎉 What's New?
worbox-background-sync
size()
. [#2941]🐛 What's Fixed?
injectManifest
. It returns now returns a warning and continues with execution. [#2959]🎁 Thank you
To our new contributors in this version: @StephanBijzitter and @fuzail-ahmed!
v6.3.0
: Workbox v6.3.0Compare Source
Workbox v6.3.0 includes a couple of bug fixes and several new features.
🎉 What's New?
Allow precaching "repair" when using subresource integrity
Although unexpected, there are edge cases where the precache might not be in an inconsistent state, most likely due to a developer manually deleting something in DevTools.
When this happens,
workbox-precaching
defaults to falling-back to using a network response (assuming the device is online) when there's a precaching miss. Up until now,workbox-precaching
hasn't attempting to use this network response to repopulate the precache, because there are no guarantees that the network response corresponds to the version of the asset specified in the precache manifest.However, if the precache entry includes an
integrity
property, then subresource integrity guarantees that the response does correspond to the same version of the asset in the manifest. So it should be safe to "repair" the cache with that response. [#2921]IDB writes use relaxed durability
This small change to the way Workbox writes to IndexedDB should lead to slightly better performance, without any appreciable downsides. [#2934]
notifyAllClients option in BroadcastCacheUpdate
BroadcastCacheUpdate
usespostMessage()
to notify all open tabs controlled by the current service worker about a cache update. This default behavior is not changing.Setting
notifyAllClients: false
when configuringBroadcastCacheUpdate
and the associated plugin will result inpostMessage()
only communicating the update to the specificwindow
client that triggered thefetch
request which resulted in the cache update. [#2920]All WorkboxEvents TypeScript types are now exported
This enhancement makes it easier to use TypeScript to write
workbox-window
event handlers. [#2919]Debug logging when caching responses with Vary: headers
The presence of
Vary:
headers on a cachedResponse
can make it difficult to properly match and delete cache entries. To make it clearer to developers when this is happening, the development builds of Workbox will now log a message to theconsole
when aResponse
that's being cached includes aVary:
header. [#2916]🐛 What's Fixed?
workbox-cli
chokidar
dependency, for betternode
compatibility and to eliminate security warnings. [#2913]workbox-precaching
PrecacheCacheKeyPlugin
. [#2914]v6.2.4
: Workbox v6.2.4Compare Source
🐛 What's Fixed?
onSync
andhandler
ingenerateSW
'sruntimeCaching
should not fail validation. [#2911]v6.2.3
: Workbox v6.2.3Compare Source
🐛 What's Fixed?
@types/trusted-types
todependencies
ofworkbox-window
[#2909]v6.2.2
: Workbox v6.2.2Compare Source
Workbox v6.2.2 fixes a few bugs introduced in the v6.2.0 release.
🐛 What's Fixed?
Validation fix for plugin functions passed to
runtimeCaching
in the build tools. [#2901]Ensure that our
tsc
configuration transpiles newer language features down to the ES2017target
level. [#2902]Update to our
lerna
configuration to use the--exact
tag when publishing tonpm
, to ensure that all the mutual dependencies in the monorepo use exact version matches, and not^
versions. [#2904]v6.2.1
Compare Source
v6.2.0
: Workbox v6.2.0Compare Source
Workbox v6.2.0 includes a number of bug fixes and internal refactoring described below.
Our intention is not to include any breaking changes in v6.2.0, and we've made an effort to maintain the same public interfaces and general behaviors while rewriting some of Workbox's internals.
🎉 What's New?
workbox-build TypeScript rewrite
The
workbox-build
module has been rewritten in TypeScript, following the earlier migration of theworkbox-cli
module. (workbox-webpack-plugin
has not yet been migrated.) Developers who useworkbox-build
from their own TypeScript code should benefit from the official, accurate type definitions that are now published alongsideworkbox-build
. [#2867]Build tool option validation
As part of this change,
workbox-build
now uses the TypeScript definitions as the source of truth when validating the configuration options developers provide. Previously,joi
was used for validation with its own set of schema, and this would sometimes lead to mismatches between what the validation logic thought was okay and what the code actually expected. Developers who inspect the validation errors returned byworkbox-build
will likely see different error strings in v6.2.0. We expect that moving forward, using TypeScript as the source of truth will lead to fewer of those mismatches.This change applies to bothworkbox-cli
andworkbox-webpack-plugin
, as well, which rely onworkbox-build
under the hood.IndexedDB code migration
Another refactoring is the replacement of our previous custom IndexedDB logic with the
idb
library. No developer-visible changes are expected due to this migration. [#2838]Multiple controlling events during a page's lifetime
Following this change,
worbox-window
'scontrolling
event is fired each time the underlyingoncontrollerchange
event happens. Multiplecontrolling
events can occur on a long-lived page in which multiple service worker updates take place.isExternal: true
will be set when the service worker that takes control is "external," which will always be the case for multiple updates.Previously,
controlling
would only be fired once per lifetime of the page, which does not match the documented behavior. This change is considered a bug fix to match the expected behavior, and developers are encouraged to test their logic to ensure that they were not relying on the previous, buggy behavior. [#2817]TrustedScriptURL support in workbox-window
Developers who have opted-in to the CSP policy
"require-trusted-types-for 'script'"
and who are using TypeScript would have previously had trouble usingTrustedScriptURL
s inworkbox-window
. This release improves that support. [#2872]rangeRequests option in runtimeCaching
Setting
rangeRequests: true
inside of aruntimeCaching
configuration entry will add the RangeRequestsPlugin to the service worker generated by Workbox's build tools. [#2871]🐛 What's Fixed?
workbox-core
HandlerDidErrorCallbackParam
type definition is now exported alongside the other relevant TypeScript types. [#2886]workbox-webpack-plugin
webpack
'seval-cheap-source-map
is used along with theInjectManifest
plugin. [#2847]workbox-window
ports
was missing on theWorkboxMessageEvent
. It's been added, mirroring the value of the underlyingMessageEvent
, when used in anonmessage
handler. [#2874]The
WorkboxEventMap
type definition is now exported alongside the other relevant TypeScript types. [#2870]Thanks!
Thank you @rockwalrus for contributing a PR [#2857] that went into this release!
v6.1.5
: Workbox v6.1.5Compare Source
Workbox v6.1.5 includes fixes in
workbox-cli
,workbox-window
andworkbox-webpack-plugin
. Also, therollup
and@rollup/plugin-node-resolve
dependencies were updated.(There was no v6.1.3 or v6.1.4 release.)
🐛 What's Fixed?
workbox-cli
In the configuration file generated by
workbox wizard
the regex forignoreURLParametersMatching
are now serialized correctly, as before they were being serialized as strings and that was causing errors. [#2796]workbox-window
Added support for external controlling events. The
controlling
event is now dispatched whether it originated in the current or external service worker. Developers can check theisExternal
flag to distinguish between the two. [#2786]workbox-webpack-plugin
Fix to push an Error object to
compilation.warnings
instead of strings, since pushing strings causes the warnings to not be bubbled up correctly. See [#2790]Thanks!
Thank you @jcabak for contributing documentation updates [#2808]!
v6.1.4
Compare Source
v6.1.2
: Workbox v6.1.2Compare Source
Workbox v6.1.2 includes several fixes to the
workbox-cli
'swizard
mode, and removes some potentially confusing logging.🐛 What's Fixed?
workbox-build
workbox-build
was used, due to an update to the@rollup/plugin-replace
plugin that it uses. The underlying issue raised in the warning message has been addressed. [#2772]workbox-cli
Previously, the
wizard
question flow would not give developers the opportunity to specify a value to override the defaultignoreURLParametersMatching
setting. Thewizard
now provides some context and explicitly asks about overriding this value. [#2763]There were two issues fixed in the
wizard
related to entering theglobDirectory
value: the separator characters,--------
, were inadvertently selectable, and additionally, the logic was buggy when a manual directory name was entered. Both of these issues are fixed. [#2766]workbox-strategies
Thanks!
Special thanks to @ognjenjevremovic for contributing the two
workbox-cli
PRs that went into this release!v6.1.1
: Workbox v6.1.1Compare Source
Workbox v6.1.1 includes a bug fix for the
NetworkFirst
strategy, as well as some documentation and TypeScript fixes.🐛 What's Fixed?
workbox-strategies
The
NetworkFirst
strategy uses two promises: one for the network request, and one is the optionalnetworkTimeoutSeconds
option is set. If the network request succeeds, then the timeout promise's timer is canceled. However, the strategy previously attempted to wait until both promises resolve before the handler resolves. This meant that, if the network request succeeds before the timeout, the strategy's over handler promise would not properly resolve.See #2744
Thanks!
Special thanks to @joshkel for both bringing that
NetworkFirst
issue to our attention, as well as contributing the code for the fix!v6.1.0
: Workbox v6.1.0Compare Source
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 aRouter
allows you to configure "fallback" logic if any handler invoked by thatRouter
returns an error. It can be awkward to use, however, if you have many differentRoute
s registered for the sameRouter
, and you would prefer that the fallback logic only be invoked when one or two particularRoute
handlers fail.Starting in this release, each individual
Route
object has asetCatchHandler()
method, allowing you to add fallback logic just to thatRoute
, without affecting any otherRoute
s. To use this method, make sure you explicitly construct aRoute
first, and then pass thatRoute
to the (overloaded)registerRoute()
method:See #2699
New "recipes"
The
workbox-recipes
module has been extended with a few new features: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.warmCache
option to page, image, and static resource recipes to allow users to warm those caches.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 astatus
code less than400
as being cacheable (including opaque responses, which have a status code of0
). Developers who need to customize this behavior can pass acacheWillUpdate
plugin toworkbox-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 customcacheWillUpdate
criteria) is encountered, installation will consistently fail and the invalid response won't be added to the cache.See #2738
workbox-webpack-plugin
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 #2735All build tools
source-map
dependency has been updated to resolve an issue that could occur when run in a Node environment that had a polyfilledfetch()
. See #2716Thanks!
Special thanks to @Spiderpig86 for contributing a PR that was part of this release.
v6.0.2
: Workbox v6.0.2Compare Source
Workbox v6.0.2 resolves an issue that could prevent
workbox-precaching
from working as expected when loaded viaworkbox-sw
.(There was no v6.0.1 release.)
🐛 What's Fixed?
_handle
. [#2687]Thanks!
Special thanks to @pidtuner for raising the issue that was resolved in this release.
v6.0.0
: Workbox v6.0.0Compare Source
Overview of Workbox v6
We're happy to announce the release of Workbox v6!
🎉 What's New?
webpack improvements
This release includes additional bug fixes for better compatibility with
webpack
. As of this release,workbox-webpack-plugin
requireswebpack
v4.40.0 or later (for those still on the v4.x branch) orwebpack
v.5.9.0 or later (for those who have updated towebpack
v5.x).workbox-webpack-plugin
will also now take advantage of theimmutable
metadata thatwebpack
automatically adds to hashed assets. In most cases, this means that explicitly usingdontCacheBustURLMatching
in yourworkbox-webpack-plugin
configuration is no longer necessary.See #2651, #2673, and #2675.
workbox-strategies improvements
The best way to ensure third-party developers have the power to extend Workbox in ways that fully meet their needs is to base our own strategies on top of the extensibility mechanisms we expose to third-party developers.
Specifically, v6 introduces a new way for third-party developers to define their own Workbox strategies, and all of our built-in strategies have been rewritten on top of this mechanism.
This change also allowed us to rewrite the
workbox-precaching
codebase to useworkbox-strategies
as a base. This should not result in any breaking changes, and should lead to better long-term consistency in how the two modules access the network and cache.See #2446, #2459 and #2569 for more details.
New strategy base class
In v6, all Workbox strategy classes (both built-in strategies as well as custom, third-party strategies) must extend the new
Strategy
base class.The
Strategy
base class is responsible for two primary things:A new "handler" class
We previously had internal modules call
fetchWrapper
andcacheWrapper
, which (as their name implies) wrap the various fetch and cache APIs with hooks into their lifecycle. This is the mechanism that currently allows plugins to work, but it's not exposed to developers.The new "handler" class (which this proposal calls
StrategyHandler
) will expose these methods so custom strategies can callfetch()
orcacheMatch()
and have any plugins that were added to the strategy instance automatically invoked.This class would also make it possible for developers to add their own custom, lifecycle callbacks that might be specific to their strategies, and they would "just work" with the existing plugin interface.
New plugin lifecycle state
In Workbox v5, plugins are stateless. That means if a request for
/index.html
triggers both therequestWillFetch
andcachedResponseWillBeUsed
callbacks, those two callbacks have no way of communicating with each other or even knowing that they were triggered by the same request.In this proposal, all plugin callbacks will also be passed a new
state
object. This state object will be unique to this particular plugin object and this particular strategy invocation (i.e. the call tohandle()
).This allows developers to write plugins where one callback can conditionally do something based on what another callback in the same plugin did (e.g. compute the time delta between running
requestWillFetch
andfetchDidSucceed
orfetchDidFail
).New plugin lifecycle callbacks
In order to fully leverage the plugin lifecycle state (mentioned above), you need to know when the lifecycle of a given strategy invocation starts and finishes.
To address this need (and others), the following new plugin lifecycle callbacks will be added:
handle()
method returns a response. This callback can be used to modify that response before returning it to a route handler or other custom logic.handle()
method returns a response. This callback can be used to record any final response details, e.g. after changes made by other plugins.Developers implementing their own custom strategies do not have to worry about invoking these callbacks themselves; that's all handled by a new
Strategy
base class.More accurate TypeScript types for handlers
TypeScript definitions for various callback methods have been normalized. This should lead to a better experience for developers who use TypeScript and write their own code to implement or call handlers.
See #2548.
workbox-recipes
This release includes a new module,
workbox-recipes
, that combines common routing and caching strategy configurations into ready-to-use code that can be dropped in to your service worker.You can read more about what's included in the first batch of recipes, as well as how to use them, in #2664.
workbox-window improvements
New messageSkipWaiting() method
A new method,
messageSkipWaiting()
, has been added to theworkbox-window
module to simplify the process of telling the "waiting" service worker to activate.This offers some improvements over alternatives:
It calls
postMessage()
with the de facto standard message body,{type: 'SKIP_WAITING'}
, that a service worker generated by Workbox checks for to triggerskipWaiting()
.It chooses the correct "waiting" service worker to post this message to, even if it's not the same service worker that
workbox-window
was registered with.See #2394.
Removal of "external" events in favor of an isExternal property
Many developers were confused by the concept of "external" events in
workbox-window
, and in practice, they did not end up being a net-positive.All "external" events are now represented as "normal" events with an
isExternal
property set totrue
. This allows developers who care about the distinction to still detect it, and developers who don't need to know can ignore the property.See #2031.
Cleaner "Offer a page reload for users" recipe
Taken together, these two changes make the "Offer a page reload for users" recipe cleaner:
sameOrigin parameter in matchCallback functions
A new boolean parameter,
sameOrigin
, is passed to thematchCallback
function used inworkbox-routing.
It's set totrue
if the request is for a same-origin URL, andfalse
otherwise.This simplifies some common boilerplate:
See #2487.
matchOptions are supported in workbox-expiration
You can now set
matchOptions
inworkbox-expiration
, which will then be passed through as theCacheQueryOptions
to the underlyingcache.delete()
call. (Most developers won't need to do this.)See #2206.
Precaching now processes entries one by one, not in bulk
workbox-precaching
has been updated so that only one entry in the precache manifest is requested and cached at a time, instead of attempting to request and cache all of them at once (leaving it to the browser to figure out how to throttle).This should reduce the likelihood of
net::ERR_INSUFFICIENT_RESOURCES
errors while precaching, and also should reduce the bandwidth contention between precaching and simultaneous requests made by the web app.See #2528.
PrecacheFallbackPlugin allows for easier offline fallback
workbox-precaching
now includes aPrecacheFallbackPlugin
, which implements the newhandlerDidError
lifecycle method added in v6.This makes it easy to specify a precached URL as a "fallback" for a given strategy when a response otherwise wouldn't be available. The plugin will take care of properly constructing the correct cache key for the precached URL, including any revision parameter that's needed.
Here's a sample of using it to respond with a precached
/offline.html
when theNetworkOnly
strategy can't generate a response for a navigation request—in other words, displaying a custom offline HTML page:precacheFallback in runtime caching
If you're using
generateSW
to create a service worker for you instead of writing your service worker by hand, you can use the newprecacheFallback
configuration option inruntimeCaching
to accomplish the same thing:Under-the-hood workbox-precaching improvements
This release includes a substantial rewrite to the implementation of
workbox-precaching
, to build on top of other standard Workbox idioms (likeRoute
s,Strategy
subclasses, and custom plugins) as much as possible. There are a few breaking changes, described in the follow section, but they are mostly limited to uncommon use cases, whenPrecacheController
is instantiated directly. For the most part, these changes are meant to be invisible to developers, but should lead to be better consistency in how routing and request handling works across all of Workbox.You can read more about what's change in #2638
cacheKeyWillBeUsed can be used to cache non-GET requests
Only
GET
requests can be used as cache keys, but there are scenarios in which you might want to use a combination of plugins to transform aPOST
orPUT
request into a cacheableGET
request.You can now use the
cacheKeyWillBeUsed
lifecycle callback in a plugin to return aGET
request with whatever URL you'd like to use as a cache key, and that can then allow the response associated with aPOST
orPUT
to be cached.See #2615 for more details. Thanks to @markbrocato for their contribution.
Build Tools
The minimum required version of node has been increased to
v10.0.0
. This applies toworkbox-build
,workbox-cli
, andworkbox-webpack-plugin
. [#2462]mode
was not intended to be a supported parameter for theinjectManifest
andgetManifest
modes ofworkbox-build
andworkbox-cli
. It's been removed from the documentation and attempting to use it outside ofgenerateSW
will now trigger a build error. This does not apply toworkbox-webpack-plugin
, which does supportmode
in itsInjectManifest
plugin. [#2464]workbox-core
skipWaiting()
method inworkbox-core
wrapped the underlying call toself.skipWaiting()
in aninstall
handler. In practice, this caused undue confusion and offered little value, as it's valid to callself.skipWaiting()
outside of aninstall
event. As of v6, Workbox'sskipWaiting()
will no longer add in aninstall
handler, and is equivalent to just callingself.skipWaiting()
. Because of this, developers should migrate to callingself.skipWaiting()
directly, and Workbox'sskipWaiting()
will likely be removed in v7. [#2547]workbox-precaching
While this scenario is uncommon, if you precache a URL that corresponds to an HTTP redirect to an HTML document on a different origin, that cross-origin HTML document can no longer be used to satisfy a navigation request. [#2484]
By default, the
fbclid
URL query parameter is now ignored when looking up a precached response for a given request. [#2532]Note: The following changes primarily apply to direct usage of the
PrecacheController
class. Most developers don't usePrecacheController
directly, and instead use static helper methods likeprecacheAndRoute()
exported byworkbox-precaching
. [#2639]PrecacheController
constructor now takes in an object with specific properties as its parameter, instead of a string. This object supports the following prConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.