Repository navigation
Conversation
| runtime: string | ||
| initialize(options: { | ||
| env?: Record<string, string> | ||
| env?: NodeJS.ProcessEnv |
There was a problem hiding this comment.
Does this allow passing SHARE_ENV from import { SHARE_ENV } from 'node:worker_threads' too?
There was a problem hiding this comment.
No. This PR deliberately only accepts process.env.
SHARE_ENV is specific to worker_threads, while Tinypool exposes the same env option for child_process. Admitting the symbol in the shared type would also require runtime validation (including the recycleWorkers({ runtime: "child_process" }) path); otherwise the process worker's object spread would turn the symbol into an empty environment.
#138 explores that larger feature and its guards. If you prefer full WorkerOptions["env"] parity, I can expand this PR with the runtime checks and tests. Otherwise, I think keeping #137 scoped to the process.env type mismatch is the safer minimal change.
|
Checking in on the scope question above. I can keep this PR limited to |
|
The author of #138 has since closed that alternative in favor of this smaller fix. This PR remains limited to accepting Would appreciate a review of the |
Closes #136
Summary
envoption fromRecord<string, string>toNodeJS.ProcessEnvprocess.envdirectly to a workerThis deliberately does not add
SHARE_ENVsupport because Tinypool also supports thechild_processruntime, where that worker-thread-only symbol is not accepted.Validation
pnpm buildpnpm typecheckpnpm lintpnpm exec vitest run test/simple.test.ts(26 passed)pnpm exec vitest run test/termination.test.ts(3 passed)The full test command was also attempted on Windows with Node 24. It reached 87 passing tests before a Vitest child process hit a heap OOM and one termination test timed out; that termination file passed when rerun in isolation.