workbox-webpack-plugin is not writing in MemoryFS in development environment

[sridharAJ]

Library Affected:
workbox-webpack-plugin

Browser & Platform:
all browsers.

Issue or Feature Request Description:
I am using webpack as my build tool. When I am using workbox-webpack-plugin in development mode, the service worker file is not stored in webpack Memory FileSystem and referring all the static assets from disk instead of memory. Because of this I am not able to use workbox in development mode. And need some example for workbox-sw with webpack in development environment.

[prateekbh]

@sridharAJ, the current webpack plugin acts on after-emit and creates the file on filesystem.
I'll take some inputs from here to make it work for dev mode.

Few questions:

1. Are you using it with webpack dev server
2. Are you trying to give a source service worker file to the webpack configuration?

[sridharAJ]

@prateekbh Thanks for your quick reply.

1. Are you using it with webpack dev server :
   Yes I am using webpack dev server.
2. Are you trying to give a source service worker file to the webpack configuration?
   service worker source file path I am giving only to workbox-webpack-plugin, not in webpack
   config.

new workboxPlugin({
    globDirectory: paths.appDist,
        staticFileGlobs: ['**/*.{js,css}'],
        swDest: path.join(paths.appDist, 'sw.js'),
        swSrc: path.resolve(__dirname, "../../src/sw.js"),
        globIgnores: ['sw.js', 'workbox-sw.prod.v1.0.0.js']
    })

[prateekbh]

cool, i'll take that as an input, btw staticFileGlobs is now globPatterns

[sridharAJ]

@prateekbh Is there any quick workaround for now, So that i can continue my development.

[prateekbh]

@sridharAJ i am not sure if there is a workaround for the memoryFS bug.
Apologies if it hurts your current development.
Just one thing, were you using anything like SwPrecacheWebpackPlugin before this in your webpack configuration?

[sridharAJ]

@prateekbh
Its okay, Then when can I expect this from you.
No I am not using any SwPrecacheWebpackPlugin in my webpack config.

[jeffposnick]

See also: https://github.com/goldhand/sw-precache-webpack-plugin/issues/74#issuecomment-303192778

[prateekbh]

@jeffposnick correct me if I am wrong, but sw-precache didn't used to write the service worker file did it?
If not this might be more work for us than it meets the eye, because we would have to make the workbox-build aware of the contents of memoryFS.

[jeffposnick]

sw-precache always wrote out the final service worker file based on the configuration options, and not based on a swSrc file, like we have with the injectManifest() approach. sw-precache was just like generateSW().

[sridharAJ]

@jeffposnick and @prateekbh Any update on this?

[ronderksen]

I ran into this issue as well. As this is a much used way of working with webpack, it would be nice to have a fix.

[gauntface]

I'm on my phone but would be good to ask Sean Larkin if he has any examples of plugins that do this.

[gauntface]

@TheLarkInn Are you aware of how we might solve this issue? Any examples / guidance would be greatly appreciated.

[prateekbh]

So I checked that eve sw-precache-webpack-plugin also doesn't support this. Also since our node module tries to read it from disk, and webpack dev server writes it to disk(I assume), hence we'll need to find a way to re-route this gap.

[NekR]

webpack-dev-server doesn't write anything to disk.

[gauntface]

I'm happy to make changes to workbox-build if someone can explain what is needed to get this working, maybe @goldhand has some ideas.

[goldhand]

@gauntface , is there a way to specify the filepaths without the files existing on the file system yet?
I think this would be possible if we could force workbox-build to accept file paths for files that don't exist yet (they haven't been wrote to the filesystem by webpack yet).

We can be certain that files will exist after webpack emits them, but we can't write to fliesystem, generate the service worker using the filepaths, then pass it back to webpack because webpack's cycle has already ended after it wrote to the filesystem the first time.

I think this would be the first step to emitting the service worker as a webpack asset, rather than writing it in the plugin.

[jeffposnick]

@goldhand Yup, there's now support for a manifestTransforms configuration option, which is one or more functions that are given the entire manifest, can do whatever they like (including adding in entries), and then return the modified version of that manifest.

There's some context about using it for supporting publicPath at https://github.com/GoogleChrome/workbox/issues/689#issuecomment-316736078, and it could theoretically be used for creating entries that only exist in Webpack's MemoryFS.

(I'm not convinced that aggressively precaching in a dev server is actually desirable, but I'm not the target audience and enough other people have asked for it that I'm willing to accept it.)

[gauntface]

If anyone gets a chance to try this would appreciate feedback or issues.

cc @goldhand @jeffposnick @prateekbh

[frlinw]

What about this part of the issue :

need some example for workbox-sw with webpack in development environment.

Is there a way to have a native support for dev env ? like copy-webpack-plugin for example which depends on webpack's in-memory filesystem in dev.

[AleCaste]

We are also in need for WorkBox support in development mode where files are written to memory and not to the filesystem.
Has anybody made any progress on this?
At present we are using manifestTransforms as suggested by @jeffposnick but it's not ideal; too much code for something that should ideally be handled by the plugin automatically.

[goldhand]

I think we have a solution for this. I haven't tested with webpack-dev-server but I'm using webpack to generate a manifest and adding it to the compilation assets.

[AleCaste]

Excellent news @goldhand !
How can we know that those changes are released for us to test the plugin on our dev environments?
Would you maybe post a note here on this thread?

[TheLarkInn]

Let me know if ya'll need any help in regards to the memory-fs realm. Most of the time webpack just swaps out the abstraction for compiler.inputFileSystem and compiler.outputFileSystem

[goldhand]

Hey @TheLarkInn! I see, so if we use fs we may have some problems?
We should use compiler.inputFileSystem._readFile instead of fs.readFile?
and compiler.outputFileSystem.writeFile instead of fs.writeFile?

I've been just inserting service worker stuff into the compilation.assets:

compilation.assets[manifestFilename] = {
  size: () => manifest.length,
  source: () => manifest,
};

This is working pretty well (when I've been testing with dev-server too).

[goldhand]

808 does everything in-memory and should fix this. I've used it with webpack-dev-server successfully.

[TheLarkInn]

@goldhand Yes that is correct. Unless your plugin has specific alt-fs needs, you should just be fine hooking into the existing fs.

[JonathanLink]

after adding this to my webpack config, I succeded in making my development environement to work:
devServer: { contentBase: './build' }
@goldhand maybe I am missing something but #808 did not help, same issue.

My package.json:
... "start": "webpack && webpack-dev-server --inline" ...

my webpack.config.js

plugins; [ ... new WorkboxBuildWebpackPlugin({ globDirectory: './build/', globPatterns: ['**/*.{html,js,css}'], swDest: './build/sw.js' })

[jegj]

Any update on this issue?

[gauntface]

@jegj we are working on it. No ETA yet.

[goldhand]

FYI, this is supported in the #808 pr. It's not ready for merging yet though

[addyosmani]

Now that https://github.com/GoogleChrome/workbox/pull/808 has landed, sgtm to close this one.