realpath for testing

[FND]

@mkhl noticed that various plugins use corutils' realpath, which is not available by default on macOS and various Linux distributions (cf. .travis.yml)

unfortunately, realpath adds another 46 packages (>1 MB) as dependencies, which seems silly:

let realpath = require("fs.realpath");

let filepath = sys.argv[2];
filepath = path.resolve(filepath);
filepath = realpath.realpathSync(filepath);
console.log(filepath);

thus we might want to offer a simplistic realpath implementation of our own - not quite sure how to do that safely though

[mkhl]

I’m still not sure why realpath is required. I haven’t felt the need to symlink test/run anywhere yet…

[FND]

I've become profoundly uncomfortable not ensuring absolute paths in cases like this:
https://github.com/faucet-pipeline/faucet-pipeline-js/blob/99c67e5dc3dcb82caf7d3245b4d7560417f8df25/test/cli/run#L5-L6

Is that excessively paranoid?

[mkhl]

I believe it is.

Let’s assume we omit the call to realpath. In order for that to cause problems, someone would have to first symlink the script somewhere and then run it manually (npm test would still run it at the correct path). I believe that a failing script is the appropriate response to that scenario.

If someone were to actually do that, what problems would arise? Loading cli-harness.sh would fail and the script would abort with a helpful error message. If someone were to fix that error by fixing the path, the next begin would fail instead, again with a helpful error message.

I don’t think I’d do anything to prevent those errors, I’d much rather ensure that npm i && npm t works on a clean clone.

[mkhl]

Oh, as a side note: I think I’d also symlink cli-harness.sh into the directories where it’s loaded in order to present a simpler environment to the test scripts.

[FND]

Done: faucet-pipeline/faucet-pipeline-js@9c80dbb (with similar commits in faucet-core, faucet-sass, faucet-static, faucet-images and nite-owl)