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
It's really more of a Node issue than a Parcel one tbh, but I think it should be tracked on both repositories, if only for better discoverability 🙂
Parcel 2 currently hangs when used with a Yarn 2 project because the workers are executed outside of the PnP context (because of nodejs/node#29117), and the error isn't properly cascaded back to the master process.
💁 Possible Solution
Apart from fixing this in Node, the alternative would be to:
Manually send the script content using the eval option from new Worker, to avoid the crash when Node tries to read the in-zip file outside of the PnP context (it would work since the master thread can call readFile on its own files without problem).
Forward the PnP path when detecting that the process is executing under a PnP environment (ie when the pnpapi name can be successfully resolved), so that the child thread can setup its own environment (ie call require(workerData.pnpPath).setup()).
Or to disable the workers codepath when detecting PnP (the process workers seem to work, as they spawn a new process which properly executes the --require entries), but that would be a shame.
The text was updated successfully, but these errors were encountered:
🐛 bug report
It's really more of a Node issue than a Parcel one tbh, but I think it should be tracked on both repositories, if only for better discoverability 🙂
Parcel 2 currently hangs when used with a Yarn 2 project because the workers are executed outside of the PnP context (because of nodejs/node#29117), and the error isn't properly cascaded back to the master process.
💁 Possible Solution
Apart from fixing this in Node, the alternative would be to:
Manually send the script content using the
eval
option fromnew Worker
, to avoid the crash when Node tries to read the in-zip file outside of the PnP context (it would work since the master thread can callreadFile
on its own files without problem).Forward the PnP path when detecting that the process is executing under a PnP environment (ie when the
pnpapi
name can be successfully resolved), so that the child thread can setup its own environment (ie callrequire(workerData.pnpPath).setup()
).Or to disable the workers codepath when detecting PnP (the process workers seem to work, as they spawn a new process which properly executes the
--require
entries), but that would be a shame.The text was updated successfully, but these errors were encountered: