toolbox supports precache, but readme makes it seem otherwise

[gautamarora]

The sw-toolbox readme seems to suggest that if pre-caching is required, then sw-precache should be chosen.

What if I need precaching as well? Then you should go check out sw-precache before doing anything else. In addition to precaching static resources, sw-precache supports optional runtime caching through a simple, declarative configuration that incorporates Service Worker Toolbox under the hood.

However, sw-toolbox does support precaching with the toolbox.precache.

toolbox.precache(arrayOfURLs) Add each URL in arrayOfURLs to the list of resources that should be cached during the service worker install step. Note that this needs to be called before the install event is triggered, so you should do it on the first run of your script.

Is there a particular reason why the sw-toolbox readme is so explicit in pointing users to sw-precache for precaching and not using the method available already?

The reason I am bringing up this issue is because the first time I read the readme, I assumed that sw-precache provides both precaching and runtime caching while sw-toolbox provides only runtime caching, but that was not a correct assumption.

[jeffposnick]

The "precaching" that sw-toolbox provides is a one-time addition to the a given cache, with no effort to keep those resources up to date. The most effective use of SW caching is to include versioning information about precached resources as part of a build-time process, and use that versioning information to keep those resources up to date.

It's somewhat unfortunate that sw-toolbox used the method name precache(), which ends up steering folks towards a less efficient solution. We've taken to de-emphasizing that functionality, and pointing people towards sw-precache for their precaching needs. (Or Workbox, which provides a unified interface for both pre- and runtime caching.)