Fix pnpm installs by moving binary download location

[jonathanrainer]

Fixes #1881

The Problem

This bug requires a little explanation. So, in the release of v0.23.0 of Rover we inlined the binary-install dependency to resolve a security vulnerability with axios (#1819). The inlining of this dependency caused the place where rover binaries were downloaded to change, but in such a way that it only affected installs via pnpm.

The reason for this is that the code that was inlined was using the __dirname variable to site the binary installation, and this variable always contains the path of the folder where the currently executing script is located. Normally this would not be a problem because the script ran inside the binary-install packages folder. As evidenced by running console.log against the output of trying to install the binary under Rover v0.22.0

root@3479114cabfc:/node_modules/.bin# ./rover
Binary {
  url: 'https://rover.apollo.dev/tar/rover/x86_64-unknown-linux-gnu/v0.22.0',
  name: 'rover',
  installDirectory: '/node_modules/.pnpm/binary-install@1.1.0/node_modules/binary-install/node_modules/.bin',
  binaryPath: '/node_modules/.pnpm/binary-install@1.1.0/node_modules/binary-install/node_modules/.bin/rover'
}
....

However, when the package was inlined and moved the location of the script itself changed and so therefore did the value of __dirname and so it tried to install the binary somewhere else, as evidenced by running the same commands as above but this time using Rover v0.23.0

root@44b617aea38c:/usr/local/lib/node_modules/@apollo/rover# ./run.js
Binary {
  url: 'https://rover.apollo.dev/tar/rover/aarch64-unknown-linux-gnu/v0.23.0',
  name: 'rover',
  installDirectory: '/usr/local/lib/node_modules/@apollo/rover/node_modules/.bin',
  binaryPath: '/usr/local/lib/node_modules/@apollo/rover/node_modules/.bin/rover'
}

We see here that it's now trying to install into the node_modules/.bin inside the rover package itself. This is what leads to problems because this location is already utilised by pnpm to store a shell script (also called rover) that calls out to the run.js. So under Rover v0.23.0 we end up with an infinite loop where binary.js looks for the binary, finds the one put in by pnpm, invokes it, which then looks for the binary, finds the one put there by pnpm, invokes it and so on.

Why was this not a problem when using `npm` to install?

Under `npm` the situation is different, if you install `rover` globally then the shell script that invokes run.js gets installed to `usr/local/bin/rover` which then will not conflict or form the infinite loop (as per https://docs.npmjs.com/cli/v6/configuring-npm/package-json#bin)

If you install rover as part of another npm project then the binary gets installed to the node_modules inside the rover package as it's installed as can be seen below

Binary {
  url: 'https://rover.apollo.dev/tar/rover/aarch64-unknown-linux-gnu/v0.23.0',
  name: 'rover',
  installDirectory: '/node_modules/@apollo/rover/node_modules/.bin',
  binaryPath: '/node_modules/@apollo/rover/node_modules/.bin/rover'
}

So this will not conflict either because what's specified in the bin stanza in package.json gets installed to the top level node_modules so again no conflict.

The Solution

If we stop using the __dirname variable and instead use something relative to the package.json of Rover itself all these problems disappear. This is not a known path so will not get clobbered by another package manager (pnpm or otherwise) and will allow consistency across platforms. That is what this PR proposes

Testing

Added a few more CI steps to ensure we can install in all JS domains (npm, npm (global), pnpm), as can be seen here, when run with the CI without the fix we get the following behaviour

However when run with the fix the CI check runs green, thus in future we shouldn't have this problem/it'll be caught in CI

[nmoutschen]

This LGTM and thanks for the detailed explanations! However, might be worth having an extra pair of eyes before merging this.