Path handling improvements and nested worker support

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?

[Silic0nS0ldier]

This PR brings the following;

• Support for nested workers worker starting further workers #12
• CI updates
• Dependency updates
• More test coverage
• Added .editorconfig
• More reliable path handling (particularly for Windows) absolute paths to workers in windows not working when containing a drive letter #15

TODO

• Fix for npm ci issues
• Require CJS module from inline worker
• Fix issue building with NodeJS 16 on Windows (never finishes)
• Fix for types not being included in package when published (there are other PRs that do this, I needed these changes and added it while creating a tgz artefact and didn't notice the other PRs)
• Decouple from require('worker_threads).isMainThread to avoid conflicts (e.g. AVA v4 uses worker threads)
• Add test case for threads.workerData being undefined (to address more potential worker_threads usage conflicts)
• Wait for worker events in tests instead of 500ms to account for test environment volatility.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[developit]

This is really good. No need to split things up, both pieces are improvements I'm happy to merge.

[developit]

Alright I fixed the npm ci issue @Silic0nS0ldier. If you can sign the CLA, I can take a peek at supporting CJS require from within a Worker. FWIW I don't think we need to support requiring a CJS module from within an inline module worker, since require() from modules is unsupported in Node anyway.

note: the windows node 16 build never finishes. I'm thinking we'll have to turn that variant off, something seems broken in CI.

[Silic0nS0ldier]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

@googlebot I fixed it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Silic0nS0ldier]

Had a look into supporting require in data: URLs. Reason its not supported is fairly simple, VM.runInThisContext does not provide require. Part of the reason for this is that require has context (file path), and so it is treated as a local variable (which runInThisContext ignores). If we are to do this right, a context-free require is necessary. This might be doable via module.createRequire.

Inline scripts aren't a problem for a module worker since the code is loaded via dynamic import, which handles the lack of a file path file. Fun fact, import.meta.url will return the provided data URL.

---

Had a thought, while web workers support patterns like data: (among a handful of others), they are commonly blocked in browsers by content security policy. This makes sense since this is essentially eval. It would be worthwhile throwing some obligatory warnings up, and maybe a warning on using a data string that lacks some special "I know what I'm doing" clause (a-la "use strict").

Ideally postMessage would be used to pass external data along to the worker safely, but with data URLs supported the temptation exists.

[Silic0nS0ldier]

require from a data URL is now supported, with require context being defined by process.cwd() which seems like a sensible value since something must be defined.

[Silic0nS0ldier]

Re NodeJS 16 on Windows, I think the timeout is due to a change in how NPM v7 (which comes with NodeJS 16) which when combined with a particular characteristic of this repo causes Windows to execute node.js (the repo file). Whatever is getting started from this (Windows has a JScript host, so it was either waiting for permission or got into some kind of loop) is causing the timeout.

npm/cmd-shim#40

Assuming I'm right, relocating the source should do the trick.

[Silic0nS0ldier]

Looks like I was right. NodeJS 16 on Windows just worked fine in the CI on my side. 🎊

[AwesomeStickz]

Hi, just wanted to know, is there any reason why this is still not merged yet? @developit

[Silic0nS0ldier]

Hi @developit, I figure its about time I ping you.

For those following along, I've created a release on my fork to permit easier usage in the meantime. https://github.com/Silic0nS0ldier/web-worker/releases/tag/v1.3.0-alpha.0

[schwers]

Hey there, came across this issue as well in a project our org is working on. Would it be possible to merge this in? Is there any support I could provide to help do so?

[schwers]

@developit sorry to ping, would you be open reconsidering this patch?