Simplifies creation of a service worker to serve your webpack bundles.
npm install serviceworker-webpack-plugin
The problem solved
When building a service worker, you probably want to cache all
your assets during the
But in order to do so, you need their names.
That's not simple when you are using Webpack:
- The assets names are non-deterministic when taking advantage of the long term caching.
- The assets list can even evolve over time as you add splitting points or more resources.
- You want to be able to use your service worker with the dev-server mode of Webpack.
- You want to keep the build process as simple as possible.
1. Add the plugin to your webpack config
2. Register the service worker in your main JS thread
;if 'serviceWorker' in navigatorconst registration = runtime;
3. Write your own
You can now use the global
serviceWorkerOption variable in your
E.g. In our example this object looks like:
You can have a look at the
folder if you need a full working example.
entry, required, string: Path to the actual service worker implementation.
filename, string, default
'sw.js': Relative (from the webpack's config
output.path) output path for emitted script.
excludes, array, default
['**/.*', '**/*.map']: Exclude matched assets from being added to the
includes, array, default
['**/*']: Include matched assets added to the
publicPath, string, default
'/': Specifies the public URL address of the output files when referenced in a browser. We use this value to load the service worker over the network.
template, function, default noop: This callback function can be used to inject statically generated service worker. It's taking a
serviceWorkerOptionargument and must return a promise.
transformOptions, function: This callback function receives a raw
jsonStatskey contains all the webpack build information.
minimize: Whether to minimize output. Defaults to
process.env.NODE_ENV === 'production'
options: That's forwarded to the
optionsargument of the
- The offline-plugin package was a great source of inspiration.
- The html-webpack-plugin package was also really helpful.
Why simply not use the
Still, soon after using it, I realized that it wasn't what I was looking for.
- The abstraction provided was too high. (I needed to build some custom fetch logic.)
- It was making me, even more, dependent on Webpack. (What if later, I want to switch to another build system?)
Hence, I decided to change the approach and created this thin layer on top of Webpack to solve the assets name issue. Nothing more.
If you don't care about my two issues with
then you don't need to use this package,
offline-plugin is great.