#2273 Webpack iterative builds broken by workbox-webpack-plugin@5.0.0-rc.0

[Anonymous]

Originally created by: amosyuen

Library Affected:
workbox-webpack-plugin

Browser & Platform:
Google Chrome 78.0.3904.87
Firefox 70.0.1

Issue or Feature Request Description:
Webpack iterative builds broken when WorkboxWebpackPlugin.InjectManifest is used at version 5.0.0-rc.0. Version 4.3.1 works fine. See example
https://github.com/amosyuen/workbox-hmr-broken

[Anonymous]

Originally posted by: jeffposnick

Hello @amosyuen!

I'm having trouble understanding what's broken. I tried running your example from GitHub locally, and first off, it doesn't actually register the service worker that ends up being generated, so I don't think there's anything amiss due to service worker involvement. (In general that's a good idea, since I'd recommend not registering a service worker when using hot module reloading, since the service worker's caching might interfere with getting the latest updates.)

I do see the InjectManifest plugin regenerating the (unregistered) service worker multiple times after each change, but that doesn't seems to interfere with getting the updates in my experience. InjectManifest does log a warning about a potentially inaccurate precache manifest (see [#1790]), but that's expected and shouldn't have any impact since, again, the service worker isn't registered.

Here's what I see in Chrome's JS console:

Am I missing some step that's required to reproduce the breakage? Did you perhaps have an old service worker already registered on http://localhost:8080 that is mistakenly taking control? I always do local PWA development in an Incognito window to ensure that I "start fresh" without any old service workers each time.

[Anonymous]

Originally posted by: amosyuen

Hey @jeffposnick it's not about the service worker, actually this might not be titled poperly, it seems that the webpack plugin breaks the webpack iterative build process. When I tested, I made sure there was no service worker attached.

Wanted to verify, did you follow the instructions in the README? The problem is if you make a change to the files. e.g. Change "Title" -> "Title2" in app/main.js, the website will not get updated. Even if you hard refresh the window it will not get updated. You have to restart webpack to get the new files.

To clarify the use case, while I don't want cacheing in dev, I do want to be able to register a service worker for push notifications and other logic. However, just introducing the wokrbox plugin (without registering the service worker) breaks webpack updating.

[Anonymous]

Originally posted by: amosyuen

For anyone else experiencing the same problem, For now I've found that using https://github.com/NekR/offline-plugin works for me. No problem with iterative rebuilding in webpack and you can disable cacheing in dev by setting the excludes config to **/* to exclude everything.

[Anonymous]

Originally posted by: jeffposnick

Hello!

Yes, I've followed the steps in the README but I do see the updates reflected in my open browser. I can't reproduce the issue.

Can you try this out in a Chrome Incognito window and see if you run into the same problem? I'm wondering whether a previously installed service worker, or something else that was cached, is interfering with your development flow.

[Anonymous]

Originally posted by: amosyuen

Sorry for delay, I've tried it with incognito window also and as expected same behavior. Of note, I've tried this with windows explorer, firefox, and chrome, so it is unlikely to be browser dependent.

Also since removing the plugin / downgrading the plugin makes iterative builds work again, seems to point against this being a browser side problem. I've attached the webpack-dev-server output for a run without workbox and a run with workbox. In both runs, I started with Title, changed it to Title2, then changed it again to Title3. It looks like the workbox one doesn't emit hot updates for main.js, but the one without workbox does.

webpack-dev-server-workbox.txt (github.com)
webpack-dev-server-normal.txt (github.com)

[Anonymous]

Originally posted by: amosyuen

Also additional info about version:
Node version: 10.15.1
Yarn Version: 1.19.1
OS: Windows 10 Pro N Version 1903 (OS Build 18362.476)

[Anonymous]

Originally posted by: jeffposnick

So I'm still at a loss for how to reproduce things following the steps provided, as I'm able to successfully trigger subsequent webpack builds that contain the updated code when following the steps at https://github.com/amosyuen/workbox-hmr-broken

I'm not exactly sure what to say, and I can keep this open to see if other folks have similar experiences.

Here are a few things to keep in mind that are somewhat related to the overall topic, though not direct explanations for what you're seeing:

• Using a cache-first service worker can introduce delays in seeing updates in your page's resources. However, thee repro you provided doesn't actually register the service worker, so whether it caches things or not shouldn't matter.

• There is an issue (#1790) with webpack's watch mode that leads to the full set of assets not being added to the precache manifest during subsequent builds. But again, that shouldn't matter because you're not actually registering the service worker.

[Anonymous]

Originally posted by: ms-fadaei

I have this issue too,
in webpack-dev-server hot reload broken
hard reload not working too...

Update: I use empty sw.js and also remove all options but still not working

new InjectManifest({ swSrc: './src/service-worker.js' })

[Anonymous]

Originally posted by: ms-fadaei

Update again:

This just happens in app.js (entry point) not all other scripts
I use vue.js and I edit one of my components (on the login page) and hot reload just work fine

[Anonymous]

Originally posted by: cerw

This is still happening to me on hot-reload, warning and does not update. Can hot-reload replace the manifest too ?

[Anonymous]

Originally posted by: jeffposnick

See also: https://github.com/GoogleChrome/workbox/issues/2404#issuecomment-636047946

I think that's the same scenario, and I'm not able to reproduce any issues. Can you reproduce when following along with that comment?

[Anonymous]

Originally posted by: Sharlock93

this might be a bit off-topic but I have been running into this "issue" too while trying to get this to work with Vue, I did not try to setup a project that had hand written webpack configs on it, I used the vue-cli to setup the project.

the main "solution" if you can call it that is that is to run your dev serve like this yarn serve --mode=production, this will make changes take a bit more time to compile however changes made in the source of the service worker will be updated correctly.

for some context:

• vue-cli has a plugin for pwa but you need to update the internal workbox-webpack-plugin using yarn's "resolutions" works well here, however going through the vue-cli pwa plugin code, it only outputs stuff if you are in production not during development which is quite annoying.

code for updating internal workbox-webpack-plugin, add this to your package.json file:

"resolutions": {
    "@vue/cli-plugin-pwa/workbox-webpack-plugin": "^5.1.4"
  }

• by-passing the pwa plugin and adding the workbox-webpack-plugin yourself through vue.config.js still has the problem of the changes not being reflected when you are in development mode, I believe this might be due to some config with vue-cli that caches things somewhere but I'm not too sure

here is my vue.config.js file

const {InjectManifest} = require( 'workbox-webpack-plugin')
process.env.NODE_ENV = 'development'
module.exports = {
    configureWebpack: {
        plugins: [
             new InjectManifest({
            swSrc: './src/plugin/service-worker.js',
            swDest: 'service-worker.js',
        })
    ]
},
}

[Anonymous]

Originally posted by: tropicadri

Given that we were unable to reproduce and that we've released new updates to workbox-webpack-plugin since the original report, I'm going to close this issue.

If you're still running into this issue with the current version of workbox-webpack-plugin, sharing a configuration that can reproduce the issue would be appreciated, and we can reopen at that point.

[Anonymous]

Ticket changed by: tropicadri

• status: open --> closed