lerna does not respect $PATH variable

[lucasbraun]

I want to use a different git version than the one in /usr/bin because that one is too old for lerna publish) to work. I have added my newer git version (which works with lerna) to $PATH, but lerna seems to pick the one in /usr/bin nevertheless (even if I explicitly remove /usr/bin from $PATH). I was able to track the problem down to execa which seems to be the root cause of that problem and I created a ticket there (with more information how to reproduce my problem):
sindresorhus/execa#153

Could you please integrate their changes as soon as they become available? That would be much appreciated.

Thanks!

[ThisIsMissEm]

This seems like an issue where we'd need to know what the expected behaviour of execa is in order to resolve.

[evocateur]

This isn't a lerna issue. Once the issue is resolved with execa, unless it's a major version, there's nothing for lerna to do.

[westmark]

We encountered this exact problem today. The issue is that execa defaults the option preferLocal to true, which means it will by default prepend some paths, including the path for the node executable(process.execPath). In our case it prepended with /usr/bin which contained an old version of git. This happened on a Jenkins server outside of our control and which was poorly maintained(apparently).

We don't expect execa to change this behaviour, so we propose that lerna default to sending preferLocal: false in all calls to sync(), or at least allow preferLocal to be configurable in lerna.json.

[evocateur]

How exactly does execa's preferLocal option cause this error? npm-run-path is what is actually modifying the env when preferLocal is true, but I don't see how it would prepend paths like /usr/bin by itself.

[westmark]

Yes, npm-run-path modifies the env, and thereby the PATH when preferLocalis true. Since it is true by default, the user can never trust that whatever PATH they have constructed will be respected. And like I wrote, npm-run-path will prepend the PATH with, among other things, the path where the current node executable is located, which of course will vary from system to system. On a poorly maintained system where there may be old versions of git etc. lying around, this becomes a problem.

[evocateur]

Looking deeper, I do indeed see the problem in npm-run-path. There is an open PR that needs some help. This option won't change in lerna because it is necessary to make hoisted executables work, as well as maintain parity with npm run semantics.

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.