Support for opt-in compilation in injectManifest mode

(Moving a conversation from https://twitter.com/jeffposnick/status/1286392399036588037)

To summarize, workbox-build’s generateSW and workbox-webpack-plugin’s InjectManifest both perform a compilation, using Rollup in the case of workbox-build’s generateSW, and a child compiler in the case of workbox-webpack-plugin’s InjectManifest.

workbox-build’s injectManifest, however, does not perform a compilation. It just generates a precache manifest and does string replacement to swap that manifest in for self.__WB_MANIFEST in the swSrc file.

The reasons for this (some good, some bad) are:

1. Before v5, workbox-webpack-plugin’s InjectManifest didn’t perform a compilation either. So there wasn’t an inconsistency historically.

2. The assumption is that developers who are comfortable using JavaScript modules are already using a bundler like Rollup or Parcel in other parts of their web app. Asking them to bundle their service worker using their existing bundling process isn’t a burden. (This is likely to be less true over time, as <script type="module"> support makes it easier to consume JavaScript modules in other parts of web apps without bundling.)

3. Not every developer has migrated to using Workbox via JavaScript modules. Many of them still use workbox-sw to load in Workbox’s runtime via importScripts(), especially if they’ve migrated code from v4 or earlier. Bundling of their service worker isn’t required in that case.

4. It arguably makes more sense for the recommended steps to be “use Rollup with a plugin that handles injectManifest” as opposed to “use injectManifest with a configuring that runs Rollup automatically”.

I’m not sure if any of those reasons are great given how developers are using JavaScript in 2020, and I’m personally open to exploring a mode in workbox-build that does both automatic compilation and manifest injection—probably not for v6, though.

[jeffposnick]

If someone finds this thread and wants a one-liner that made use of npx executions of esbuild and workbox-cli (chained together), the following works:

npx esbuild src/service-worker.ts --bundle --define:process.env.NODE_ENV=\"production\" --outfile='/tmp/service-worker.js' && npx workbox-cli injectManifest

(assuming you have a local workbox-config.js file configured with swSrc: '/tmp/service-worker.js'). If you’d prefer not to write to /tmp/, you could output from esbuild directly to your build directory, and then use that path for both the swSrc and swDest options, and workbox-cli injectManifest will overwrite the file with the version that contains the injected manifest.

I really like esbuild, and the fact that it’s a) fast and b) can handle TypeScript compilation and bundling and process.env.NODE_ENV at the same time, without plugins, is great. That being said, if we had implemented the original feature request back when folks asked for it, chances are it would have been done using Rollup (which we still use for generateSW mode). The fact that the bundler tooling ecosystem is improving so quickly is, I think, an argument for not baking that functionality into injectManifest, and instead letting developers take advantage of all the improvements being made in the toolchain of their choice.

[TheForsakenSpirit]

As user of Create-React-App + TypeScript + injectManifest (we try to build offline first app), that not able to configure webpack directly (without ejecting), I would rather have a compile mode. And many users of CRA as I see, too. Because now I must use backdoor with node script for compilation of my SW.