[Snyk] Upgrade workbox-routing from 6.0.0-alpha.3 to 6.1.5 #3
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.
Snyk has created this PR to upgrade workbox-routing from 6.0.0-alpha.3 to 6.1.5.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
Release notes
Package name: workbox-routing
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]!
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!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!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: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.
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.
Read more
Overview of Workbox v6
We're happy to announce the first release candidate of Workbox v6! We do not anticipate any more breaking changes in between now and the official v6 release.
In addition to the changes outlined in the previous release notes, the following has changed since Workbox v5.
🎉 What's New?
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.
webpack v5 compatibility 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.4.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.
Thanks!
Thank you to @ dermoumi for their contributions to this release.
Installation of the latest pre-release version
We are using the
next
tag innpm
for the current pre-release version. To install a given module use, e.g.,npm install --save-dev workbox-webpack-plugin@next
.Read more
Commit messages
Package name: workbox-routing
Compare
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs