Releases: GoogleChromeLabs/sw-precache
4.0.0
What's New?
The 4.0.0 release brings with it a number of exciting and substantial changes. While the configuration options used in earlier releases should be compatible with 4.0.0, the generated service worker will use a different underlying caching technique that isn't compatible with older caches. After upgrading, your users will end up repopulating their caches.
sw-precache now uses a single cache
As mentioned, the caching logic has been modified to get to the point where we can safely include versioning information about each cached resource in the cache entry's key, meaning that we no longer need to create as many independently versioned caches as we previously did. In practice, this might lead to slightly better performance, without changing any functionality.
New dontCacheBustUrlsMatching option
By default, sw-precache adds in a cache-busting URL parameter to request URLs when populating its cache, to ensure that the response used is "fresh" and not served from the browser's HTTP cache. However, if a developer is already "doing the right thing" by explicitly versioning their static resources and setting appropriate long-lived HTTP caching headers, this cache-busting is not needed. The new dontCacheBustUrlsMatching option takes a regular expression and will skip cache-busting for any resources that match that expression.
New stripPrefixMulti option
stripPrefixMulti gives developers more flexibility over translating the paths to resources in the local filesystem to the corresponding URLs that they'll be served from.
Significant PRs Since Previous Release
- supporting multiple stripPrefix & replacePrefix entries via stripPrefixMulti
- Always run sw-precache's fetch handler before sw-toolbox's
- Move to a single cache for all responses
- cli support for maximumFileSizeToCacheInBytes
- Adds a dontCacheBustUrlsMatching option
Thanks
Thanks to @SignpostMarv, @cdbattags, and @jwagner for their PR contributions!
3.2.0
What's New?
The 3.2.0 release brings a few bug fixes, primarily around passing options to the command line interface.
It also brings with it a change to the cache-busting parameter used when populating the cache, which should make it play nicer when used in conjunction with a caching CDN proxy.
Finally, it works around an uncommon bug that could leave the cache in an unhappy state if the install handler is interrupted.
PRs Since Previous Release
- Fix typo in test.
- Remove the sourcemap comment when inlining sw-toolbox
- Fix a typo.
- Guard against empty caches due to a previously aborted install handler
- Use the expected hash as the cache busting param.
- Exclude the file passed to write() from being picked up
- Properly read in runtimeCaching option from external config file
- Adds webfont extensions to staticFileGlobs example
- chore(cli): add "maximumFileSizeToCacheInBytes"
- Update links for runtimeCaching documentation
Thanks
Thanks to @TimvdLippe, @manekinekko, @zenorocha, @jpmedley, and @halfninja for their PR contributions!
3.1.0
What's New?
navigateFallbackWhitelist
The navigateFallback option, when set, causes top-level navigation requests for a URL that isn't already cached to respond with a "fallback" HTML page being returned. This works well when there are arbitrary URLs that need to map back to the same underlying App Shell HTML document, but it's a bit of a blunt tool.
For developers who need the flexibility of only mapping some URLs to the App Shell HTML document, the new navigateFallbackWhitelist allows you to specify one or more regular expressions. Navigation requests for URLs that match at least one of those regular expressions will get the App Shell HTML document as the response, and navigation requests that don't match a cached response or one of those whitelists will be served from the network.
PRs Since Previous Release
3.0.0
What's New?
sw-toolbox Integration
sw-precache is meant to be used hand-in-hand with a runtime caching library like sw-toolbox, with sw-precache handling your App Shell and sw-toolbox handling your dynamic content.
Previously, using them both together required installing the sw-toolbox package separately and pulling it in via the importScripts option, which made a common use case overly complicated.
Now, it's possible to automatically include and configure sw-toolbox via a new sw-precache option, runtimeCaching. You can configure both your App Shell and dynamic caching strategies in one location, along the lines of:
var config = {
runtimeCaching: [{
// See https://github.com/GoogleChrome/sw-toolbox#methods
urlPattern: /runtime-caching/,
handler: 'cacheFirst',
// See https://github.com/GoogleChrome/sw-toolbox#options
options: {
cache: {
maxEntries: 1,
name: 'runtime-cache'
}
}
}],
staticFileGlobs: [
rootDir + '/css/**.css',
rootDir + '/**.html',
rootDir + '/images/**.*',
rootDir + '/js/**.js'
]
};The gulpfile.js in the demo/ directory includes a complete sample of configuring both App Shell and dynamic content caching.
Getting Started Guide
The Getting Started Guide lays out some common terminology and helps developers understand how to think about the specific caching needs of their web app.
External Config for sw-precache Command Line
Developers who prefer using the command line sw-precache binary can now store their configuration in an external JSON file. This makes it much easier to use a complex configuration without having to wrangle command line flags.
PRs Since Previous Release
2.3.0
Overview
sw-precache 2.3.0 brings with it a number of smaller enhancements and bug fixes, along with a switch over from xo-style ESLint rules to Google-style rules.
This is also the first tagged release that contains the iFixit Progressive Web App sample code, created to accompany the "Instant Loading with Service Workers" Chrome Dev Summit talk.