It's very common to use sw-precache and sw-toolbox in conjunction with each
other, especially when following the
App Shell +
dynamic content
model.
The service worker that sw-precache generates handles the local asset
versioning and uses cache-first strategy for your App Shell.
sw-toolbox handles runtime caching strategies for dynamic content, such as API
calls, third-party resources, and large or infrequently used local resources
that you don't want precached.
We wanted to make it easier for developers to use the two libraries together.
Because sw-precache has to be directly integrated with your build environment
and must be responsible for outputting your top-level service worker file, it
made the most sense as an integration point to give sw-precache the ability to
include the sw-toolbox code and configuration alongside its own
configuration. Using the
runtimeCaching
configuration option in sw-precache is a shortcut that accomplishes what you
could do manually by importing sw-toolbox in your service worker and writing
your own routing rules. You can confirm this by looking at a
sample service-worker.js
file generated by sw-precache when the
runtimeCaching option is used.
This relationship might change at some point in the future once changes to the
service worker specification make it possible to
relax the requirement
that sw-precache generate the top-level service worker.