-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for *not* writing to disk #711
Comments
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 :)
Could you describe the API changes you would like to see made here in some more detail? |
While we don't have examples of it inlined in the docs, the interface for |
@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! |
The Let me know if there's anything you'd like to see added/changed! |
Library Affected:
workbox-build, etc.
Browser & Platform:
all
Issue or Feature Request Description:
I'm migrating us from
sw-precache
toworkbox
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
andwrite
we always used thegenerate
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 likeinjectFileManifest
orgenerateSw
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.
The text was updated successfully, but these errors were encountered: