GoogleChromeLabs / worker-plugin

šŸ‘©ā€šŸ­ Adds native Web Worker bundling support to Webpack.
https://npm.im/worker-plugin
Apache License 2.0
1.91k stars 79 forks source link

Nested workers not resolved correctly output.publicPath is relative #89

Open xenobytezero opened 4 years ago

xenobytezero commented 4 years ago

I assume this is a side-effect of Angular's use of this plugin, but I can see how this could affect other setups.

Reproduction Steps

1/ Clone test repo - https://github.com/xenobytezero/worker-plugin-nested-bug.git 2/ npm install 3/ npm run build 4/ npm run testServer

This will start up a HTTP server running on localhost:5000 and show the following

screenshot-localhost_5000-2020 08 26-17_57_38

5/ Rename the serve_bug.json to serve.json and rename the existing one to something else 6/ Modify the webpack.config.js to change the output.publicPath value to be dist/

This replicates the end result of our current server setup using Angular, where the HTTP server serves the root folder, writes the publicPath to the dist/ folder, but resolves the root URL to serve dist/index.html.

7/ npm run build 8/ npm run testServer

This will start the HTTP server again and show the following

screenshot-localhost_5000-2020 08 26-18_05_03

and if you open DevTools you will see the following

Annotation 2020-08-26 180632

Investigation

I believe the problem lies in the loader.js line 87

return cb(null, `${options.esModule ? 'export default' : 'module.exports ='} __webpack_public_path__ + ${JSON.stringify(entry)}`);

The plugin writes the module.exports to prefix the path with the Webpack public path (__webpack_public_path__), which in this case adds a second /dist onto the path and produces a 404.

Also a much less important side effect, nested Workers get a second .worker on their built filename. No real effects, just looks weird.

Proposal

I've been trying to come up with a solution for this, and I think my lack of Webpack experience is getting in the road. Essentially the path used in the line above should be relative to the source file rather than just the public path.

developit commented 3 years ago

Hiya! This is actually a misconfiguration: dist/ is not a valid webpack publicPath value, since it is a relative path - you can use /dist/ instead:

output: {
  publicPath: '/dist/'
}

This should fix the issue. Let me know if that worked!

xenobytezero commented 3 years ago

Thanks for the response.

Unfortunately using /dist/ breaks the compilation of the rest of the application, as all my webpack bundles are now written into the HTML with a /dist/ src and appear to totally ignore my <base href> tag. I feel like <base> should override this, but it doesn't appear to be.

developit commented 3 years ago

<base> is an HTML feature and does not apply within workers. Try adding this to the very top of your main worker file:

__webpack_public_path__ = '/dist/';
DarrenCook commented 2 years ago

I'm having this problem from within a Quasar project (quasar 1.x, webpack 4.x). When I use quasar dev to start it in the dev environment, the nested worker has been working fine. But when I use quasar build it builds it in to dist/spa/ and then it has not been finding it. It has been trying to load /js/js/0.6c08f3ad.worker.worker.js when the file is actually at /js/0.6c08f3ad.worker.worker.js

I've confirmed that if I create a js sub-directory, and move that file in there, then everything works.

Inside "js/0.07631c92.worker.js" is this (minified) code:

ed3b:function(e,a,n){e.exports=n.p+"js/0.6c08f3ad.worker.worker.js"}

I imagine n.p is either '' or '/js/', when what is needed is '/'

So, following the above comment, inside quasar.conf.js, in the build section, I added:

  publicPath:'/',

This seems to have done the trick, as now both quasar dev and quasar build is working. Thanks for the hint!

DarrenCook commented 2 years ago

It seems that fix doesn't work for Electron builds, though. quasar dev -m electron is okay, but quasar build -m electron is failing to load file:///...path/to.../app.asar/js/js/0.worker.worker.js. I can see it is exactly the same code in 0.worker.js as in my previous comment.

Any suggestions would be welcome. It is going to be more complicated to hack around this one, with a packaged-up Electron file, than it was with the web app.

(Let me know if I should start a new issue for this.)