nested volta invocations

[chriseppstein]

When code in a javascript project that uses volta tries to execute a volta-controlled binary in another javascript project that also uses volta, the behavior is not what one would expect. The PATH environment variable will be set to the binary versions that the first-invoked project uses.

Here's some typescript code that I wrote to work around this issue:

export function restoreVoltaEnvironment() {
  let voltaHome = process.env["VOLTA_HOME"];
  if (!voltaHome) return;
  let paths = process.env["PATH"]!.split(path.delimiter);
  while (/\.volta/.test(paths[0])) {
    paths.shift;
  }
  paths.unshift(`${voltaHome}/bin`)
  process.env["PATH"] = paths.join(path.delimiter);
}

I'm curious whether this sort of workaround is expected for these situations? If so, does the code I've written here look reasonable?

[toshok]

We've run into this with a volta installed CLI (gsts) that re-spawns itself. Unfortunately in this case we really don't have any recourse.

[charlespierce]

@chriseppstein Can you talk more about the use-case of one JS project calling a tool that is managed by Volta in another project directory? Specifically how you would expect it to work, and how it currently works in a system without Volta?

We have issue #492 as a potential solution to a whole class of issues relating to global tools interacting with each other, which may be a solution, though in the initial brainstorm it would still result in only a single version of Node.

@toshok That's an interesting case, can you expand on it? Does it fail, or is it that it uses an unexpected version of Node?

[chriseppstein]

@charlespierce In my situation, the tool isn't being distributed as a published executable. You checkout the code, yarn install and the yarn run various package scripts. The tool is used to help build and test other javascript projects so it executes yarn install and yarn run as spawned processes from within those other checked out package directories. Because it's a separate process, I expect the node and yarn versions of those other projects to match their specific volta configurations.

I think #492 is a good idea, but I don't think that it will address the issue I'm seeing -- I want a spawned process to "start fresh", if there's PATH entries that supersedes the shim directory that wouldn't work for my purposes.

I expect that most people would want spawned processes to inherit the pinned volta versions even if executed outside of their package directory. The question I have is whether volta should leave the shims in the first PATH location and intelligently check if the current process invocation has a volta pin that applies and if not, then to fall back to other PATH entries.

[charlespierce]

@chriseppstein Short term, since you control the code that's launching these other tools, I think that your workaround makes sense to "reset" the environment so Volta starts fresh. Longer term something like #492 may also provide the behavior you need. However, there are a lot of unanswered questions (several of which you note) about what the most common expected behavior will be, which is why we have that issue marked as "Needs RFC". We'll need to hash out the possible flows and determine what makes the most sense for the majority of use-cases.

[charlespierce]

@toshok I see the code in gsts that respawns itself, and why it doesn't work currently with Volta. I think that will be fixed by #492 regardless of the decisions about environment, but until that lands it doesn't look like it will work cleanly. We could potentially open an issue in gsts to have it be more agnostic about the environment when it respawns itself, not relying on the assumption that gsts is on the PATH.

[toshok]

re: our problem, it fails to respawn with ENOENT:

$ which gsts
/Users/toshok/.volta/bin/gsts
$ gsts
User is not authenticated, spawning headful instance
events.js:288
      throw er; // Unhandled 'error' event
      ^

Error: spawn gsts ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
    at onErrorNT (internal/child_process.js:469:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
    at onErrorNT (internal/child_process.js:469:16)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn gsts',
  path: 'gsts',
  spawnargs: [
    '--headful',
    '--awsProfile=sts',
    '--awsSharedCredentialsFile=/Users/toshok/.aws/credentials',
...
  ]
}

PATHs seem to point out the proximal "why" (same as original issue):

$ echo $PATH
/Users/toshok/.volta/bin:/Users/toshok/.goenv/shims:...

$ node -e 'console.log(process.env.PATH)'
/Users/toshok/.volta/tools/image/node/12.16.1/6.13.4/bin:/Users/toshok/.volta/tools/image/yarn/1.22.4/bin:/Users/toshok/.goenv/shims:...

[charlespierce]

@toshok It's a super small fix, so I just submitted a PR (and associated issue) to gsts: ruimarinho/gsts#6

[charlespierce]

@toshok That change landed and was published, so gsts@2.1.4 should now work with Volta.

@chriseppstein Closing in favor of #492 as the overall approach to fixing tools interacting with other tools.

[charlespierce]

@nhhockeyplayer Can you clarify your question? Where is that error log from?

Volta doesn't have any direct association with NX or GitHub Actions (other than that we publish our own GitHub Action that you can use in your own workflows). Volta itself is a tool for managing Node versions. The above error message seems to be from a command that is attempting to run a Volta command without having Volta installed.