Provide a way to read files not from the filesystem

[justinfagnani]

We use sw-precache in a gulp-like pipeline, and it's be nice to just provide the files directly.

[jeffposnick]

This is similar to https://github.com/GoogleChrome/sw-precache/issues/39

I'd be curious to see what the pipeline and serving environment looks like. sw-precache makes some assumptions right now about what URL will be used for each local resource based on filesystem paths. Supporting something other than reading files from disk would require finding a way to pass in a corresponding URL for each resource.

[justinfagnani]

Here's the build pipeline: https://github.com/Polymer/polymer-cli/blob/master/src/build/build.ts

The slightly ugly part is that we break the normal pipelining and have to wait for everything to write to the filesystem until we configure and run sw-precache.

[eirslett]

+1

sw-precache-webpack-plugin doesn't work with webpack-dev-server because the dev server holds all assets in memory (fast incremental builds), and that makes much it harder to work with sw-precache + webpack.

Most state-of-the-art JavaScript build tools today seem to be written with that in mind; everything is held in memory, and flushing to disk is the last, most expensive step.

[jeffposnick]

I'm sympathetic to the gulp-pipeline use case for a production-y build.

I'd suggest that using sw-precache in a webpack-dev-server environment is a bad idea anyway, since it will actively defeat all the live-reload benefits (since assets will be served cache-first, ignoring changes until the next reload), and the fact that there aren't navigations in between resource updates fights against the service worker upgrade flow.

sw-precache can be used with handleFetch set to false to just generate a service worker file without implementing a fetch handler, and that's normally the best bet if you do need to generate a service worker in your dev environment, but it's only useful in that case as a sanity-check as to what's being cached.