workbox-webpack-plugin: webpack --json hangs

[klinki]

Library Affected:
workbox-webpack-plugin.

Browser & Platform:
Webpack 4.1.1, workbox-webpack-plugin 3.0.0

Issue or Feature Request Description:
When I run webpack --mode production --json it hangs infinitely.

After I remove

    new GenerateSW({
      // these options encourage the ServiceWorkers to get in there fast 
      // and not allow any straggling "old" SWs to hang around
      clientsClaim: true,
      skipWaiting: true,
      
      globDirectory: outDir,
      globPatterns: ['**/*.{html,js}'],
      swDest: path.join(outDir, 'sw.js'),
    })

from webpack.config.js, it works.

[freezy]

Same here, hangs at 95% emitting GenerateSW. I've also tried with a minimal config:

new WorkboxPlugin.GenerateSW({
	swDest: join(options.outputPath, 'sw.js'),
	clientsClaim: true,
	skipWaiting: true
})

Same versions of webpack and workbox-webpack-plugin as @klinki.

EDIT: To reproduce, check this repo (it's not minimal though).

git clone https://github.com/vpdb/website
cd website && git checkout workbox3
npm install && npm run build:prod

[jeffposnick]

Re: @klinki, does removing the globDirectory/globPatterns options lead to anything different in your setup? In most cases, it's not necessary to mess around with globs in workbox-webpack-plugin v3, as it will automatically pick up files from your webpack asset pipeline. I'm curious if removing those leads to different behavior. Also, could you post your complete webpack configuration?

Re: @freezy,

$ git clone https://github.com/vpdb/website
$ cd website && git checkout workbox3
$ npm install && npm run build:prod

completes without issue for me. (Testing on OS X, using node v9.8.0.) Are you seeing this 100% of the time, or just periodically? And which operating system are you using?

[freezy]

Running on Windows 10 x64, node 8.5.0, tried around 10 times, always hangs. Also tried removing all options but the three mentioned above with the same result. I've also tried with a fresh clone / npm install.

[jeffposnick]

Okay, it might be a Windows thing. That's a lead, at least.

[freezy]

Or a node thing. :)

[jeffposnick]

Okay, I can reproduce it following @freezy's steps on Windows 10/node 8.10.0.

@klinki, are you using on Windows?

[jeffposnick]

@freezy, the issue you're seeing is because you're using a full Windows absolute path for swDest (i.e. C:\Users\blah\AppData\Local\Temp\website\dist\sw.js). workbox-webpack-plugin makes use of that swDest value as the path to the service worker asset it creates, and it looks like webpack (v4?) is unhappy with absolutel paths:

workbox/packages/workbox-webpack-plugin/src/generate-sw.js

Line 103 in ed2a847

compilation.assets[this.config.swDest] = convertStringToAsset(swString);

As a fix for now, you could just pass in a path that's relative to the webpack output directory. So, something like 'sw.js' would be fine, if you want to generate the service worker at the root of the output directory.

I'd imagine we can just fix that by using, e.g., path.relative() to convert any absolute paths that are passed in into a path relative to the output directory. But it's probably also worth creating a standalone reproduction and filing a bug with the webpack team, because being able to stop a webpack build from completing by doing that in a plugin doesn't seem right.

[freezy]

@jeffposnick thanks for your investigations, really appreciated!

Your suggestion works well and there isn't really a reason for using absolute path names, I don't even remember why I did it this way.

I'll have a look at a repro repo tonight if nobody beats me to it. Cheers!

[djeeg]

Following over from the comment i had on the other issue:

Yep - im windows too

Dont work

swDest: path.resolve(__dirname, "../../../output/webpack", process.env.APP_ENV, "sw.js"),
swDest: path.join(__dirname, "../../../output/webpack", process.env.APP_ENV, "sw.js"),

As a fix for now, you could just pass in a path that's relative to the webpack output directory

Do work

swDest: "sw.js",
swDest: "../sw.js",

Thanks for the workaround

[klinki]

@jeffposnick I'm also on windows. I will try the suggested workarounds.

Update: It works, I set swDest to sw.js and now everything is working again :)

Thanks @jeffposnick !