Simpler InjectManifest replacement behavior

Currently, InjectManifest mode in Workbox’s build tools works by first generating a precache manifest, and then using a regular expression to find the appropriate empty array to swap out from your source service worker file.

The end result is that something like workbox.precaching.precacheAndRoute([]) in your source file is transformed to workbox.precaching.precacheAndRoute([{url: '...', revision: '...'}, ...])

The regular expression used to find just the [] that’s used as a parameter to the precaching method is a bit gnarly, and while it is possible to customize it, I don’t know that in practice it ends up being overridden much. (I know that I personally have to look up the syntax and go through a lot of trial-and-error to get a custom pattern working.)

I’d like to update this behavior in v5 to be more straightforward, and rely on simple string replacement, looking for self.__WB_MANIFEST in the service worker source file, and replacing it with the corresponding precache manifest as part of the build process.

That means that you could write workbox.precaching.precacheAndRoute(self.__WB_MANIFEST) in your source file, and things would work as before. Since self.__WB_MANIFEST will just be undefined prior to building, this should result in the unbuild service worker file being valid JavaScript.

Developers who need to manual control over adding extra manifest entries could do something like workbox.precaching.precacheAndRoute([{url: '...', revision: '...'}, ...].concat(self.__WB_MANIFEST)), which is a lot more difficult to do with the old regular expression replacement. Similarly, this would make it easier to post-process the precache manifest via runtime (as opposed to build time) JavaScript, like

const processedManifest = (self.__WB_MANIFEST || []).map((entry => {
  // return some transformation
});
workbox.precaching.precacheAndRoute(processedManifest);

(I don’t see runtime JavaScript manipulation as being a replacement for build-time manifest manipulation, but as something that would augment what you could do with build-time logic.)

I’m leaving this issue open for discussion in case there are any use cases I’m not aware of that this would end up breaking.

[jeffposnick]

In v5, one option might be just listing your swSrc file as a standalone entry when you’re in a development build mode, alongside your other entry points, and not use the InjectManifest plugin at all. That will tell webpack to perform the compilation/bundling (which InjectManifest would otherwise do for you), but not to try to do anything related to generating a precache manifest.

Or… just use the exclude config to exclude everything, as you say.

[piotrekwitkowski]

(@jeffposnick as it is probably by-design, I am posting here and not opening a new issue)

In our project we were using workbox-webpack-plugin and different entry points for dev builds (without registering sw and without plugin) and for production builds (with GenerateSW).

Once we wanted to implement push notifications and push handling,

1. we switched to InjectManifest,
2. we included

workbox.precaching.precacheAndRoute(self.__precacheManifest);

but commented it out during dev builds. We had also other registered routes, but I found it very handy not to precache files when using webpack-dev-server, to see changes faster and still be able to support push.

Now (v5) it’s not longer possible to comment out the line like this

// precacheAndRoute(self.__WB_MANIFEST);

because of the ERROR in Can't find self.__WB_MANIFEST in your SW source. error. I understand that this is by design, but maybe it could be just warning instead of a build error?

I suppose, that probably the recommended way to exclude files from precaching would be… using exclude parameter in the config 😅. But…

Are there some sensible alternatives that can work during compilation of swSrc, if I don’t want to have different workbox configs? Of course one can noop(self.__WB_MANIFEST) or console.log it and it builds, but that’s just a very stupid workaround. I will be grateful for tips how you see it guys!