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
Due to the combination of this line and the hoisting done on installs, any dep in your tree which installs node will result in all calls via run-node to use it, even if the top level project did not intend this behavior. The only workaround I can see without changes to this lib is to also install node of your own version at the top level of each project.
I think that parsing json in bash to determine if it is a top level dep is a hard problem best avoided, but IMO this bug makes this module actively harmful in the contexts which I have seen it used. One idea I had, which would resolve it in the use case I encountered this, is to use npm_node_execpath if it exists as the first check. This would at least ensure that if it was run in the context of a package.json script with npm it would use the same node version found in the parent process. I am happy to open this PR if this seems like a good resolution to the problem above.
The text was updated successfully, but these errors were encountered:
One idea I had, which would resolve it in the use case I encountered this, is to use npm_node_execpath if it exists as the first check. This would at least ensure that if it was run in the context of a package.json script with npm it would use the same node version found in the parent process. I am happy to open this PR if this seems like a good resolution to the problem above.
👍🏻 That makes sense to do regardless of this issue.
https://github.com/sindresorhus/run-node/blob/master/run-node#L4
Due to the combination of this line and the hoisting done on installs, any dep in your tree which installs
node
will result in all calls viarun-node
to use it, even if the top level project did not intend this behavior. The only workaround I can see without changes to this lib is to also installnode
of your own version at the top level of each project.I think that parsing json in bash to determine if it is a top level dep is a hard problem best avoided, but IMO this bug makes this module actively harmful in the contexts which I have seen it used. One idea I had, which would resolve it in the use case I encountered this, is to use
npm_node_execpath
if it exists as the first check. This would at least ensure that if it was run in the context of a package.json script withnpm
it would use the same node version found in the parent process. I am happy to open this PR if this seems like a good resolution to the problem above.The text was updated successfully, but these errors were encountered: