ExternalRuntime command searching slightly incompatible with nodenv

Open
#59 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript, nodejs, ruby
Domain
developer-experience, tooling

Research direction

Start by reading the ExternalRuntime command-search logic and reproducing the nodenv shim case described in the issue. Determine how an unusable node shim should be treated and verify that the runtime can fall back to JavaScriptCore when appropriate.

Written by the indexing model from the issue text.

Description

(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.

Dominant language
Ruby
Stars
578
Forks
286
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rails/execjs

All issues in rails/execjs

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.