Repository navigation
workers: --require module injects module to worker thread #28518
Description
- Version: v12.5.0
- Platform: Mac
- Subsystem: worker_threads
Steps to reproduce:
- Create two scripts, a.js:
const { Worker } = require('worker_threads');
const worker = new Worker('console.log(42)', { eval: true, data: {} });and b.js:
const { isMainThread } = require('worker_threads');
console.log('b', isMainThread);- Run
node --require b.js a.js - Take a look on output:
b true
b false
42I am wondering is it feature or bug that we inject --require module to workers. If it is feature, should we mention it in workers doc and in --require flag description?
In my use case - I use --require to implement inspector socket discovery in user land - I need --require only for main thread. I can workaround it on my side but do we need some additional flag that will inject to workers instead of reusing existing flag.
Activity
alexkozy commentedon Jul 3, 2019
cc @addaleax
devsnek commentedon Jul 3, 2019
i wouldn't expect this to happen, but it's not exactly a leap to want this behaviour either...
maybe we can add a flag to workers to disallow loading these (default enabled)
cjihrig commentedon Jul 3, 2019
Just noting that both
child_process.fork()and theclustermodule behave this way as well.Fishrock123 commentedon Jul 3, 2019
Is this really not expected? This seems to me as if it would be working as intended.
Fishrock123 commentedon Jul 3, 2019
The documentation is, unfortunately, not very clear about side-effects: https://nodejs.org/dist/latest-v12.x/docs/api/cli.html#cli_r_require_module
addaleax commentedon Jul 3, 2019
From the
Workerconstructor options documentation:So, yes, inheriting CLI flags is intentional, and there is a way to override this, and I would say that this seems like a documentation visibility issue than a bug?
alexkozy commentedon Jul 3, 2019
Should we split process-only options (e.g.,
--title) and all other in two different groups in documentation? It will give me explicit signal where each option works. Since from my use case point of view--requireshould be process-only option, but in case of custom module loader it should be process and worker option - it might be source of confusion.In my use case I am not controlling spawning workers or creating child processes, so I can not override it. I can workaround it on my side by checking for worker in required module but I prefer
--process-requireoption that will inject module only to process or maybe some generic option modifier that can make any options process-only, e.g.--process-only --require a.js --proces-only --inspect.doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options
doc: visibility of Worker threads cli options