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
(I thought a bit about how to correct this corner case without significant updates to the library, but didn't come up with anything that I could send over.)
When using nodenv to handle different node versions, but not having a global node version available, the ExternalRuntime logic breaks down. This is due to nodenv providing a path-accessible shim for the node binary regardless of whether it actually points to a valid node install. So, execjs will get through load time successfully, but fall over at runtime when actually shelling out to node.
Here is the gist of the environment:
$ which node
/Users/jimmy/.nodenv/shims/node
$ node
nodenv: node: command not found
The `node' command exists in these Node versions:
4.2.1
4.2.6
4.4.0
5.4.0
6.10.0
7.4.0
This can be avoided by explicitly preferring JavaScriptCore (assuming OSX), but I saw that the order of these was purposely swapped so I assume there are reasons things are the way they are currently. Ideally execjs wouldn't be picking up this install in the first place, and then falling back to JavaScriptCore on its own.
Not a big deal, as it is easily worked around, but it was a gotcha nonetheless and I wanted to make you aware of it.
The text was updated successfully, but these errors were encountered:
(I thought a bit about how to correct this corner case without significant updates to the library, but didn't come up with anything that I could send over.)
When using nodenv to handle different node versions, but not having a global node version available, the ExternalRuntime logic breaks down. This is due to nodenv providing a path-accessible shim for the node binary regardless of whether it actually points to a valid node install. So, execjs will get through load time successfully, but fall over at runtime when actually shelling out to node.
Here is the gist of the environment:
This can be avoided by explicitly preferring JavaScriptCore (assuming OSX), but I saw that the order of these was purposely swapped so I assume there are reasons things are the way they are currently. Ideally execjs wouldn't be picking up this install in the first place, and then falling back to JavaScriptCore on its own.
Not a big deal, as it is easily worked around, but it was a gotcha nonetheless and I wanted to make you aware of it.
The text was updated successfully, but these errors were encountered: