Closed CodeF53 closed 1 year ago
Attempted to make a test suite on stackblitz, the file upload limit stopped me from uploading the .wasm
s for everything other than OxiPNG.
https://stackblitz.com/edit/jsquash27?file=app.vue
What is really interesting to me is that stackblitz is the first thing that supports WebAssembly threads.
Thanks for the submission and work on this!
I'll try take a look again next weekend. ~From my testing I don't think this actually solves the problem and Vite won't properly extract the relevant files in a production build. Perhaps the best work around the Vite bug would be adding a config option to always use the single thread code~. Edit: This was caused by a dynamic import, I've fixed in #28
Given this test for wasmFeatureDetect.threads(), 0/8 people I asked had a device/browser that gave WebAssembly threads support: true. So I can't find anyone that could test this code for me
For the threads()
method to return true
, the server will need to set some special security headers for the served HTML page. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#security_requirements for the requirements.
@CodeF53 I think I may have a solution for use case.
When you get a spare moment can you try the following:
npm install -S @jsquash/oxipng@1.0.1
npm i -D rollup-plugin-replace-worker-import-meta-url
Update your Nuxt config with something similar to:
import replaceWorkerImportMetaUrl from 'rollup-plugin-replace-worker-import-meta-url';
// https://nuxt.com/docs/guide/directory-structure/nuxt.config
export default defineNuxtConfig({
build: {
transpile: ["@jsquash/oxipng"],
},
vite: {
optimizeDeps: {
exclude: ["@jsquash/oxipng"],
},
plugins: [replaceWorkerImportMetaUrl()]
},
});
I think 🤞 this may solve yours and others problems with Vite and Nuxt. Thanks again!
Edit: The above might work, but it's not the correct solution. The import.meta.resolve
is not compatible with Vite. I think we need a fix upstream in Vite.
@jamsinclair
@CodeF53 I think I may have a solution for use case.
When you get a spare moment can you try the following:
* Install the latest jsquash/oxipng package 👉 `npm install -S @jsquash/oxipng@1.0.1` * Install this Rollup Plugin 👉 `npm i -D rollup-plugin-replace-worker-import-meta-url`
Update your Nuxt config with something similar to:
import replaceWorkerImportMetaUrl from 'rollup-plugin-replace-worker-import-meta-url'; // https://nuxt.com/docs/guide/directory-structure/nuxt.config export default defineNuxtConfig({ build: { transpile: ["@jsquash/oxipng"], }, vite: { optimizeDeps: { exclude: ["@jsquash/oxipng"], }, plugins: [replaceWorkerImportMetaUrl()] }, });
I think 🤞 this may solve yours and others problems with Vite and Nuxt. Thanks again!
Edit: The above might work, but it's not the correct solution. The
import.meta.resolve
is not compatible with Vite. I think we need a fix upstream in Vite.
Doesn't work for me
ERROR Unexpected early exit. This happens when Promises returned by plugins cannot resolve. Unfinished hook action(s) on exit: 6:05:05 PM
(vite:worker) transform "/home/f53/proj/WebPackXBR/utils/bulk/optimize.worker.ts?worker"
(vite:worker) transform "/home/f53/proj/WebPackXBR/utils/bulk/process.worker.ts?worker"
I can't be bothered to make a minimum viable recreation right now, so here is my repo with those changes applied https://github.com/CodeF53/WebPackXBR/tree/f19d8e82b516c85795f54844ccc994c23b035d81
Thanks @CodeF53! It's also really useful sometimes to see how the code is actually used.
I can get the fix working if I also add the plugin to worker.plugins
.
import replaceWorkerImportMetaUrl from 'rollup-plugin-replace-worker-import-meta-url';
// https://nuxt.com/docs/guide/directory-structure/nuxt.config
export default defineNuxtConfig({
build: {
transpile: ["@jsquash/oxipng"],
},
vite: {
optimizeDeps: {
exclude: ["@jsquash/oxipng"],
},
plugins: [replaceWorkerImportMetaUrl()]
},
worker: {
format: 'es',
plugins: [replaceWorkerImportMetaUrl()],
},
});
Although this fix is not correct, it will make Vite completely ignoring bundling the multi threaded workers 😅 .
I've created PR in Vite and will see if we can get support to fix it, that will be the actual solution 🤞
Thanks again for the PR @CodeF53 👏 , I'll close this as unfortunately it doesn't solve the root problem.
We now have a quick solution for your needs, I have published special single thread only builds of the following packages:
The long term solution would be to get this bug fixed in Vite. If you can help give a thumbs up/heart reaction on this issue and PR it would help let maintainers know the popularity and scope of users interested in a solution 🙏
Explanation of changes
This is the problematic code used in starting multithreaded workers that lead to Vite builds breaking
I replaced all instances of that code with this:
Which is effectively identical to the code in the context I found it in.
Testing
This fixes builds in Vite for me, and works perfectly for all my tests of the example code and OxiPNG.
Problem is, I could not replicate a scenario in which the multi threaded code is ran, as I can't get into a context where
wasmFeatureDetect
thinks supports threads.Given this test for wasmFeatureDetect.threads(), 0/8 people I asked had a device/browser that gave
WebAssembly threads support: true
. So I can't find anyone that could test this code for me