web-worker

Hi, Glad to stumbled on this neat project and looking forward to using it to write more consistent browser-node code. I'm trying to get duckdb-wasm working in node, I found a example in their repo. It fails when I run it, with error: It uses web-worker, and it seems like the worker code (clearly CJS and with file extension ) gets detected like an ESM module. Downgrading web-worker from to fixes the issue. I tried a few other things like passing type: commonjs, type: classic - none worked. Suggests a regression in 1.5.0 release (edit: unless changing the default behavior in 1.5.0 is intentional) Thanks Declan

Simply having an import to inside a NodeJS worker thread with no will result in the following error: Reproduction Notes I saw that #40 tried to fix this issue already, but didn't fix it completely. The fix assumes is set to a value. If it is , we still run into the same issue as described in #40: [...] When using this library within a worker thread, the code is executed, rather than the code which creates the worker polyfill. [...] This change executes only if the property is present from the , indicating that it's being executed from a thread created within this library. If isn't present, this means that the code is executing within the context of some other worker thread that wasn't created from this library, and it needs to treat the current thread as the main thread by executing .

This PR fixes #57 I added a to the destructuring to ensure we have a valid value to destructure. In addition to that I added a new attribute with a unique name (includes a UUID, so it's basically impossible to set this by accident) to the . This ensures we can reliably verify that we are running in a worker thread, which was created by . All other threads will use the code path (and not the code path). Something similar was already suggested by eshaz in #40: [...] One enhancement might be to randomize the property name. This change assumes that a parent thread won't send a property in the ...