Allow for dynamic webpack public paths

[googlechromelabs]

Allow for dynamic webpack public paths

[skmvasu]

@developit I'm also facing a similar problem. I'm publishing a library which internally uses a Sharedworker. When bundling this, the sdk.js, and my worker.js are generated.

The problem is when the client imports sdk.js, it's part of it's vendor bundle. However worker file is not on the clients public path.

This is the code that gets generated by the plugin:

    './node_modules/worker-plugin-shared/dist/loader.js?{"name":"0"}!./src/sdk/socket/worker.ts': function(
      e,
      t,
      n,
    ) {
      e.exports = n.p + 'js/0.70afebd5.worker.js';
    },

The generated worker file is not available in the publicPath of the client. Not sure how this can be handled. @developit any thoughts on how to handle this?

[skmvasu]

Makes sense. Thanks for taking a look :)

We're exploring a few options. Will update if something works.

[developit]

@ScottPeterJohnson hmm - wouldn't this work though? The plugin generates a URL based on webpack_public_path, which you are assigning a new value to.

One thing I wanted to clarify - setting webpack_public_path in your code will never change asset locations on disk. For that you need to set the output.publicPath Webpack configuration option.

[ScottPeterJohnson]

Looking into this further it seems like the __webpack_public_path__ might be effectively global, but the generated entry for the service worker will be called before the entry that uses it.

Here's what I'm looking at, though I can't find the source or documentation on how webpack does this so it's pretty much unreadable. https://gist.github.com/ScottPeterJohnson/caa0051a8bad7f287683f23b5175b61e

__webpack_public_path__ translates to r.p, set on line 65. Line 69 (the generated entry) will be called before it on line 67.

Admittedly I might be doing something wrong? My use case seems simple enough: I just want users of my library to be able to specify the path where my worker will be loaded from.

[developit]

@ScottPeterJohnson Sorry for the delayed reply. I think you're right that this is a timing issue, but I can't think of any way to defer WorkerPlugin's usage of __webpack_public_path__ / r.p - it's only reading that value when the module gets executed (the first time it gets required on the client).

I think we might be able to fix your issue though, and it doesn't require a change in webpack or Worker Plugin: the key is that you need to set __webpack_public_path__ in your code before requiring anything.

In your app's entry file, this just have the assignment before anything else:

// src/index.js
__webpack_public_path__ = window.hashwall_asset_path;
require('./rest-of-your-app');

Note that Webpack will transform any __webpack_public_path__ assignment in your modules to r.p = .., so there's no need to modify webpack itself.

[developit]

@skmvasu what do you have output.publicPath set to in your Webpack configuration?

Are you setting __webpack_public_path__ to something at runtime?

[skmvasu]

@developit. I've not set the publicPath inthe webpack outputs.

No haven't overriden the __webpack_public_path__ either, I guess what's happening is that, when the client is installing my npm package, the main.js file is added in the vendor bundle by webpack. And the worker.js is NOT copied inside the static/js folder.

This is my build folder structure:

static/
   vendor.js
   js/
     1.js
     2.js
    // worker.js is NOT available here
     ..... 

I'm guessing that, copying the generated worker code manually to static/js should fix this problem.

Please let me know if this make sense. Will give it a try on Monday and update here.

[developit]

Ah - I didn't realize this was a module you were distributing via npm. Honestly there's no consensus on Workers should be published to npm, I'm not sure this plugin or any other could provide a solution that works in more than a handful of cases.

[developit]

@skmvasu just happened upon your reply here and wanted to point you at an npm module myself and Guy Bedford recently released that we hope may offer a fix for distributing Worker-based libraries to npm:

https://github.com/developit/web-worker

[skmvasu]

@developit this is wonderful. I'll check this out this week and see if this works for us.

[kimyvgy]

I got the same issue when using CDN.

Web App is running at http://localhost:3000. It loads JS files from the CDN at http://localhost:4000.

The SharedWorker is blocked because it is not same origin:

DOMException: Failed to construct 'SharedWorker': Script at 'http://localhost:4000/f2b8a59.worker.js' cannot be accessed from origin 'http://localhost:3000'.

I'd like to request the feature for dynamic webpack public path. If options.publicPath is provided, we will use it instead of __webpack_public_path__.

For example:

// webpack.config.js

    publicPath: 'http://localhost:4000',
    plugins: [
      new WorkerPlugin({
        sharedWorker: true,
        globalObject: 'window',
        publicPath: 'http://localhost:3000'
      })
    ]