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
All 8 comments
$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
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.
wiltzius
on 25 May 2018
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
alex-dixon
on 25 May 2018
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).
dawnmist
on 28 May 2018
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
pidupuis
on 4 Jun 2018
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.
jeffora
on 5 Jun 2018
Supposedly coming in 1.9.0. Consider the following workaround.
x-yuri
on 29 Jun 2018
This may be fixed with #6382 and #6178 (already released, IIRC), and possibly may also need #7057.
jasongrout
on 22 Feb 2019
Related issues
FLGMwt
路
3Comments
torifat
路
3Comments
jviotti
路
3Comments
victornoel
路
3Comments
sebmck
路
3Comments
Most helpful comment
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.
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).