web-worker

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 ...

I recently ran into a bad trap: I had another in the code of the child and not only in the parent. This doesn't work, because the function is then executed again. The symptom is that messages are received twice in the worker. This was hard to figure out. Note that this is not really a user's error, because a web worker is normally allowed to start another web worker. So it makes sense in general. (In my code, I could simply comment the bad out, though.) I guess that you need to split into two files for this, because the main/worker dichotomy doesn't work anymore when workers can start workers.