webpack dev server support?

[oliviertassinari]

Reading the README of the project you say that webpack dev server is not supported. I may be able to help.
But first I need to understand, what the limitations are about?
We could extend the API of serviceworker-webpack-plugin to accept a generated service worker string.

[goldhand]

@oliviertassinari I think the issue is that webpack-dev-server serves bundles from memory. This plugin saves a service worker to your build directory. It isn't an input asset for webpack so the service worker isn't bundled or anything (intentionally but there could be other approaches).

[oliviertassinari]

Thanks, so I feel like I'm going in the right direction. I will try to work on it next weekend.
We should be able to simplify the implementation here.

[goldhand]

Thanks @oliviertassinari let me know how it goes or if you have any more questions 😄

[domfarolino]

@oliviertassinari any luck so far?

[oliviertassinari]

I haven't found time to work on it yet. I'm delaying every week, it's a shame 😁 .

[aweary]

@oliviertassinari any chance you could share whatever progress or ideas you have on making this work? I'd really like to get this working for electrode-io/electrode#40 and am happy to put in the work on it.

[oliviertassinari]

@aweary The most challenging part of building serviceworker-webpack-plugin was integrating with the webpack plugin API so that it's serving the sw.js and updating it as soon as changes are made.

Here is what I have in mind:

1. Exposing a callback API (at the serviceworker-webpack-plugin level) that would allow users to inject some static code into that service worker generated. That would take the asset paths object as a first argument.
2. Use the generated API to get the service-worker code that is following the options provided by users.
3. Integrate 1. and 2. under the hood so the API exposed keeps the same.

[oliviertassinari]

I think the issue is that webpack-dev-server serves bundles from memory

Right, I though I could have bypassed this limitation with the generated API, but no. sw-precache is still looking in the file system to run some checks.
I have made some wrong assumptions.

I'm closing this issue. I'm gonna use the precache API of sw-toolbox.

I couldn't go further than:

import swPrecache from 'sw-precache';

// ...

      new ServiceWorkerWebpackPlugin({
        entry: path.join(__dirname, 'src/sw.js'),
        excludes: [
          '**/.*',
          '**/*.map',
          '*.html',
        ],
        publicPath: `${__dirname}/`,
        template: (serviceWorkerOption) => {
          return swPrecache.generate({
            staticFileGlobs: serviceWorkerOption.assets,
          });
        },
      }),

[acanimal]

Any solution?

I'm working in a project which uses webpack-dev-middleware so de bundle.js and style.css files and generated on the fly while developing and only are created witin the public/assets folders in production.

The problem, as you comment, is if I specify the

        staticFileGlobs: [
          './public/assets/style.css',
          './public/assets/bundle.js',
        ],

The files are not included in the service-worker code because they really not exists and are generated on the fly by webpack-dev-middleware.

Is there a way to bypass that limitiation and always include the specified files in the service-worker code? Is it possible and easy to add that options?

Thanks

[goldhand]

@acanimal not yet. I will reopen the issue though since there seems to be some demand for this feature.

[acanimal]

Thanks. I follow the code and seems all the values specified in the staticFileGlob options are passes to google sw-precache plugin, so I open an question: GoogleChromeLabs/sw-precache#230

[phun-ky]

Tip: use the write-file-webpack-plugin plugin, this will ensure that the given files are written to disk in in dev ;)

https://github.com/gajus/write-file-webpack-plugin

[goldhand]

Does anyone have an example of using @phun-ky suggested write-file-webpack-plugin to get this plugin working with webpack-dev-server?

[cescoferraro]

@phun-ky @goldhand @f If I get this right, if I run both this plugin with write-file-webpack-plugin, my "sw.js" is gonna be forced to written to the file system, and if running with the dev-server/node the filesystem would be memory so webpack-dev-server could catch up?

new WriteFilePlugin({
    // Write only files that have "sw.js" extension.
    test: /\sw.js$/,
    useHashIndex: true
})

[cescoferraro]

@goldhand I am pretty young and dumb about webpack in general, but the actual file write operation on ly happens here.
https://github.com/goldhand/sw-precache-webpack-plugin/blob/master/src/index.js#L141
as stated here 60frames/webpack-hot-server-middleware#13 simpler plugins like
https://github.com/unindented/stats-webpack-plugin create in-memory files just fine on my node setup.
https://github.com/unindented/stats-webpack-plugin/blob/master/index.js#L13-L31
I think all we need is access to the compiler object, right?
Cant we apply the same approach here? Maybe another boolean option to choose between writing to the file system or memory?

[NekR]

Problem here is that this plugin uses separate tool (sw-precache) and that tool isn't tied to webpack by any means, so it simply writes to the file system now knowing that webpack is intended to write to memory-fs.

[jeffposnick]

@ragingwind released https://github.com/ragingwind/sw-precache-webpack-dev-plugin recently.

I can't personally vouch for it, and I've never seen the need to have sw-precache work with your webpack-dev-server environment (since I'd normally want cache-first service worker behavior disabled when doing local development), but it might be worth trying out if you see the need?

[NekR]

@jeffposnick yeah, I thought about it as rare case too, but some people need to test locally push notifications or other SW features, so they use it. But that's still rare case, most often they just do it even though their envs becomes unusable after that.

General suggestion: if you don't use push/sync/etc events in your SW -- just disable it in dev and check "if it's still working" on a separate server (e.g. http-server) with productions build or simply on staging server.

[jeffposnick]

sw-precache (and presumably the Webpack plugin) has the handleFetch parameter for that use case, where you still want a service worker generated (perhaps to pick up things that are pulled in via importScripts, like push notifications), but you don't want any of the fetch logic to kick in.

That's what I'd kind of think would be ideal for a local developer environment.

[goldhand]

@cescoferraro, your thoughts are correct, that is the summary of the problem. I don't know how young you are but you're not dumb.

I want to test @ragingwind solution for webpack-dev-server, if that works, I will use it to add webpack-dev-server support to this plugin. As @jeffposnick mentioned, I also typically do not want super strong caching strategies implemented while I'm developing but there is no question that there is a strong demand for this feature.

[goldhand]

Looks like using the compiler option, as @cescoferraro mentioned, will solve this. See this solution

[ragingwind]

First of all, It has a very limited case of using. The reason why I made up another plugin for sw-precache instead of making a new PR is that I also think that test and development with sw-precache while developing is not a quite frequency of demand.

However, A few of people, get started with SW recently, who around me would like to test, debug and watch what's going on service worker in local because they wanted to change configurations frequently while they were developing. So, it was released as another plugin named +dev with a limited purpose.

Secondly, that plugin doesn't use officially exported APIs from sw-precahse, Using indirection of way for hashing and listing file's path

If I would thought that It's a very useful feature for most of case and built in strong, I will make a new PR.

[goldhand]

@ragingwind I would love to see a pr for this feature. This is the longest running thread/issue with this plugin. I like your dev plugin but I feel that adding a dev configuration flag to this plugin so users can easily opt in to dev support would be really convenient.

[jlbates]

I'm really missing this right now. 👍

[goldhand]

Unfortunately, there is no way for sw-precache to work with webpack-dev-server. sw-precache uses paths on the file system to generate the service worker. They don't exist on the file system so this will not be possible.

[ragingwind]

@goldhand I'm sorry for receiving no answer from me. Meanwhile, I was looking for another way to make it to support working on webpack-dev-server for a new PR. However, It reached that there is no way for working on web-deb-server unless and until sw-precache supports various files-system, as you mentioned in readme. So, I wouldn't make a PR with vary unstable and workaround code.