URL path generated for Worker imports doesn't work with Webpack about emscripten

[dr-matt]

I've hit this issue as well after recently updating emsdk. What is the disposition here? Is there a workaround that doesn't involve manual patching?
edit: reverting to v3.1.57 is one workaround - that seems to be the last version before this change in url construction.

[Twinklebear]

The issue may have been missing the -sPTHREAD_POOL_SIZE=1 (or otherwise creating a worker to run a thread in the C code), since without that the allocateUnusedWorker function isn't called. I've opened a PR to fix the generated JS code and update the test: #22165

[sbc100]

Hmm.. it seems odd to me that new URL(import.meta.url) doesn't work as expected. shouldn't that be exactly the same as new URL('basename.js', import.meta.url)?

If webpack is expanding import.meta.url to "file:///Users/will/repos/webgpu-cpp-wasm/web/src/cpp/wgpu_app.js" then that would be wrong even in the later case above, no? Or is that expansion not happening when URL is constructed with two argument?

[sbc100]

Regarding the self-dependency, do we really want to suppress that warning? I mean, the file really does depend on itself.. that is how it works.. we don't want webpack to thing any different do we?

[sbc100]

@RReverser does new URL('{{{ JS_FILE }}}', import.meta.url) make sense for some reason over new URL(import.meta.url) when trying to get the URL of the current file?

[Twinklebear]

I hadn't found it in the docs earlier, but looking at webpack's docs on import.meta: https://webpack.js.org/blog/2020-10-10-webpack-5-release/#importmeta :

import.meta.url is the file: url of the current file (similar to __filename but as file url)

So it sounds like new URL(import.meta.url) translating to the file:// URL is expected behavior from webpack.

In the native worker support section they mention using the new Worker(new URL("file.js", import.meta.url)) syntax: https://webpack.js.org/blog/2020-10-10-webpack-5-release/#native-worker-support . It seems like Vite is similar: https://vitejs.dev/guide/assets#new-url-url-import-meta-url ? I'm not much of a web bundling expert though. So maybe using new URL('{{{ JS_FILE }}}', import.meta.url) is the right pattern for bundlers?

Omitting the .href and having the circular dependency is fine for me (it also sounds like it may cause Vite to not process things the way someone would want?). In our app we add the release version to our JS file names so they're unique whether webpack renames them or not.

[sbc100]

I'm trying to reproduce the issue using webpack in our test harness, but I'm struggling to do so.

I've added a webpack test that includes EXPORT_ES6 here: #22142

However, I can't seem to make it work with pthreads, with or without EXPORT_ES6.

[RReverser]

@RReverser does new URL('{{{ JS_FILE }}}', import.meta.url) make sense for some reason over new URL(import.meta.url) when trying to get the URL of the current file?

Yeah the former is recognised as a pattern by a lot of bundlers, but the latter isn't, even though in runtime they'd be the same, yes.

[sbc100]

@RReverser does new URL('{{{ JS_FILE }}}', import.meta.url) make sense for some reason over new URL(import.meta.url) when trying to get the URL of the current file?

Yeah the former is recognised as a pattern by a lot of bundlers, but the latter isn't, even though in runtime they'd be the same, yes.

Damn.. thats kind of a shame. IMHO, the later is much cleaner since its independent of that actual filename.

The former requires that extra tempting step, more characters, and is not portable across file renames.

[sbc100]

I'd be happy to see a PR submitted to fix this, and hopefully it can come with and update to test_webpack_es6 that reproduces this failure and shows that its fixes.