You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When user runs ts-node ./index.ts and the code spawns worker_threads and/or child_processes, these should also be able to require().ts files.
This already happens with node --require ts-node/register, since that's inherited by child processes and worker threads.
Should we make our ts-node bin entrypoint behave the same way?
yarn uses NODE_OPTIONS='--require .pnp.js' to hook their PnP API into the runtime. nyc uses some sort of child_process.spawn monkey-patching, but they also don't support worker_threads. Why don't they use NODE_OPTIONS?
Are there performance concerns? Can we avoid child processes/threads re-resolving tsconfig when the parent has already done so? By passing the necessary config via an env var, or maybe prepending a --require /tmp/ts-node-config-497f86.cjs?
The text was updated successfully, but these errors were encountered:
Curious if there's any updates regarding this issue almost a year later, we've used ts-node exclusively in production for awhile, but we're having to move away from it as the worker_threads implementation can't find a .js file that doesn't exist, requiring us to build and run from node directly.
Is there a pull request for this? Are you able to send one to be reviewed? Have you tried the recommended approaches above?
Those approaches already work with ts-node in worker threads today. If you've tried them, did they work, or were there blockers?
Answers to these questions will help to triage this issue.
When user runs
ts-node ./index.ts
and the code spawns worker_threads and/or child_processes, these should also be able torequire()
.ts
files.This already happens with
node --require ts-node/register
, since that's inherited by child processes and worker threads.Should we make our
ts-node
bin entrypoint behave the same way?yarn
usesNODE_OPTIONS='--require .pnp.js'
to hook their PnP API into the runtime.nyc
uses some sort ofchild_process.spawn
monkey-patching, but they also don't support worker_threads. Why don't they useNODE_OPTIONS
?nodejs/node#36531
nodejs/node#29117
Are there performance concerns? Can we avoid child processes/threads re-resolving tsconfig when the parent has already done so? By passing the necessary config via an env var, or maybe prepending a
--require /tmp/ts-node-config-497f86.cjs
?The text was updated successfully, but these errors were encountered: