Open fmerg opened 1 year ago
@fmerg Solution would be requiring web-worker
dependency. If you are bundling for the browser, you need to exclude it.
Something like
{
input: 'src/merkleTreeWorker.ts',
output: [
{
file: 'static/merkleTreeWorker.umd.js',
format: "umd",
esModule: false
},
],
treeshake: 'smallest',
external: ['web-worker'],
plugins: [
esbuild({
include: /\.[jt]sx?$/,
minify: false,
sourceMap: true,
target: 'es2016',
}),
nodeResolve(),
commonjs(),
json(),
replace({
'process.browser': 'true'
})
],
}
Also look at the process.browser replace as the process object doesn't exist for browsers ( I think it is intended to support bundlers like webpack, but for rollup.js you need to manually replace it to true statement )
So either circomlibjs or ffjavascript would work inside Web Workers and node:worker_threads. Except that you need to bundle the worker file to use only either node.js or browser module.
I have a CPU intensive operation over JubJub, which I want to split into parallel tasks and offload to different worker threads. Each worker needs a
eddsa
instance to work with. My context does not allow for shared memory among workers and transferringeddsa
to the worker threads is also not possible in any feasible way. I would like each worker to create its owneddsa
instance:However, importing
circomlibjs
inside the worker module raises an error when the worker starts running:The exact error depends on the multithreading library in use. The above one is raised with
workerpool
. If I use the nativenode:worker_threads
or web workers for the browser, I get something likeI do not face import issues with other libraries. I wonder if this is my fault (that is, if
circomlibjs
should be imported in a different way inside js threads) or a bug.Any idea or hint is welcome. Thanks in advance.