$PATH-Issues since Version 1.7

[FlorianKoerner]

Since version 1.7 the wrong PHP version is used for my "postinstall" script. This is because Yarn modifies the $PATH variable.

My $PATH variable specifies a specific PHP version. It looks like this:

/usr/bin/php5.6:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

The directory "/usr/bin/php5.6" will be prioritized before "/usr/bin", because another PHP version can be found there.

Yarn inserts several directories before my $PATH variable. For example, the directory "/usr/bin", which is now prioritized before "/usr/bin/php5.6".

/usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/var/www/***/node_modules/.bin:/var/www/***/node_modules/.bin:/home/***/.config/yarn/link/node_modules/.bin:/var/www/***/node_modules/.bin:/home/***/.config/yarn/link/node_modules/.bin:/home/***/.yarn/bin:/usr/libexec/lib/node_modules/npm/bin/node-gyp-bin:/usr/lib/node_modules/npm/bin/node-gyp-bin:/usr/bin/node_modules/npm/bin/node-gyp-bin:/usr/bin:/usr/bin/php5.6:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Yarn should use a suffix and not a prefix to avoid such problems.

[FlorianKoerner]

$PATH-Variable with Version 1.6 looks like this:

/usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/var/www/***/node_modules/.bin:/var/www/***/node_modules/.bin:/home/**/.config/yarn/link/node_modules/.bin:/var/www/***/node_modules/.bin:/home/***/.config/yarn/link/node_modules/.bin:/home/***/.yarn/bin:/usr/libexec/lib/node_modules/npm/bin/node-gyp-bin:/usr/lib/node_modules/npm/bin/node-gyp-bin:/usr/bin/node_modules/npm/bin/node-gyp-bin:/usr/bin/php5.6:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

[wiltzius]

This is also causing problems for us with Python, rather than PHP.

Basically the Python virtualenv doesn't work anymore -- Python scripts we've written that are executed with yarn can no longer import the right packages since its (presumably) using a different Python installation than it used to.

FWIW this seems to affect our Linux (Ubuntu) systems but not our MacOS systems; both use virtualenv.

[alex-dixon]

Also appears to affect Clojurescript builds on Linux https://clojureverse.org/t/shadow-cljs-dependency-update-failed-failed-to-collect-dependencies-at-thhellerjar-2-2-26/2179

[dawnmist]

Affects us too - I have need to run a generation step to create typescript type definitions for a C++ server message api, and the change to yarn path has put /usr/bin before my existing path. This means that it does not pick up the newer cmake version installed in /opt/cmake/bin, with no way to override yarn without breaking the build for other developers. I cannot remove the package manager's version of cmake without losing several other packages I need with it.

Yarn should NOT be prepending /usr/bin to the existing path definitions. Ever.

$> node --version
v8.11.2
$> yarn --version
1.7.0
$> npm --version
5.6.0

Looking at the list of commits between the 1.6.0 and 1.7.0 tags, I believe that this pull request to add the directory containing node to the PATH is the likely cause of this issue.

@arcanis Can you please have a look into this, as it makes 1.7.0 unusable for anyone that has a custom script that depends on being able to set their own environment paths. Overriding people's environment is a very bad and unexpected thing to be doing. It'd be better to teach the few with multiple node installations how to set their own environment path or how to set an alias for which node to run properly instead of breaking the path for everyone else (I cannot see the need for the pull request above if people had a single version of node installed).

[pidupuis]

Need a fix please!

For those who want to downgrade until a fix comes:

curl -o- -L https://yarnpkg.com/install.sh | bash -s -- --version 1.6.0

[jeffora]

This also causes global versions of npm packages installed in /usr/local/bin to be selected over global versions installed in the global prefix directory, as the code to update the path only adds the global prefix directory if it doesn't already exist in the path.

[x-yuri]

Supposedly coming in 1.9.0. Consider the following workaround.

[jasongrout]

This may be fixed with #6382 and #6178 (already released, IIRC), and possibly may also need #7057.