Support for *not* writing to disk

[HenrikJoreteg]

Library Affected:
workbox-build, etc.

Browser & Platform:
all

Issue or Feature Request Description:

I'm migrating us from sw-precache to workbox and noticed that it assumes that you want to write a static SW script to disk. For reasons I described in my PR that you fine folks merged into sw-precache we'd like to be able to serve our /sw.js dynamically.

In short it's we don't rebuild our static assets for each environment, but still need to be able to change CDN values between several test environments and such, which of course, are referenced within our SW.

sw-precache by contrast exposed separate APIs for generate and write we always used the generate stuff since we didn't actually want it on disk:

It looks like I could accomplish what we'll need by doing getFileManifestEntries to build out that smart, prefetch-y, file manifest of goodness and just do our own simple templating to insert it. But stuff like injectFileManifest or generateSw all assumes a file path to write to and it may be cool if those things were a bit more decoupled??

We may very well be an edge case, certainly feel free to ignore me and close this, but I thought I'd raise it regardless. Seems like someone else may also benefit from decoupling the raw functionality from the disk operations.

Thanks for making awesome stuff folks! <3

When reporting bugs, please include relevant JavaScript Console logs and links to public URLs at which the issue could be reproduced.

[addyosmani]

I'm migrating us from sw-precache to workbox and noticed that it assumes that you want to write a static SW script to disk. For reasons I described in my PR that you fine folks merged into sw-precache we'd like to be able to serve our /sw.js dynamically.

Dynamically generating a SW, while not one of the more common patterns I see, is a workflow I would like us to support as long as it doesn't increase complexity for the rest of our users :)
As you pointed out, using templating + getFileManifestEntries would be one way of going about this but you're correct - we're still assuming you're writing generated artifacts to disk.

But stuff like injectFileManifest or generateSw all assumes a file path to write to and it may be cool if those things were a bit more decoupled??

Could you describe the API changes you would like to see made here in some more detail? injectManifest currently accepts a path and writes to disk. generateSw also writes to disk. Is the ask that you would prefer these to offer an option to return a stream/non-disk output you can then work off?

[jeffposnick]

getFileManifestEntries() + your own templating would be what I recommend, too.

While we don't have examples of it inlined in the docs, the interface for getFileManifestEntries() is publicly documented, and you can expect it to be continued to be supported.

[HenrikJoreteg]

@jeffposnick yeah, that's basically what I've ended up with.

I just came up with a little templating system for it and do my own "injection" of the manifest.

I don't know if there's anything particularly actionable here, just that perhaps explaining this option a bit more in the docs and/or adding a simple example of how you might do it.

Thanks folks!

[jeffposnick]

The generateSWString() method in the v3 branch was written with the Webpack plugin in mind, but should handle your use case as well:

https://github.com/GoogleChrome/workbox/blob/v3/packages/workbox-build/src/entry-points/generate-sw-string.js

Let me know if there's anything you'd like to see added/changed!