#191 (comment)

Yarn already sets the PATH when running scripts so that the right Yarn binary (and all other binaries that your application should have access to) is always in the PATH. But because execa modifies it as well (and it does it without actually knowing which paths it should use, it only makes assumptions), it ends up overriding the Yarn-generated folder. In the end, the wrong files are called.

I would strongly suggest defaulting it to false, as it's very intrusive and can lead to pretty hard to debug issues (I myself spent an indecent amount of time trying to figure out what happened before I started to consider that maybe execa was doing something strange).

Example:

package.json

{
  "dependencies": {
    "execa": "^1.0.0"
  },
  "scripts": {
    "foo": "yarn --version",
    "bar": "node ./example.js"
  }
}

example.js

const execa = require('execa');

execa('yarn', ['--version']).then(v => {
  console.log(v.stdout);
});

command line

# npm installs the bins in the same folder as Node, so `node` and `yarn` are siblings
$> npm install -g yarn@1.15.1

# This command enforces the Yarn version inside this one project
$> yarn policies set-version 1.15.2

$> yarn foo
1.15.2

$> yarn bar
1.15.1

In this case, you see that Yarn rightfully enforced the use of the 1.15.2 release when calling foo. Unfortunately, since execa overrides the PATH with dirname(node), it also overrode in the process the Yarn binary that we set in the path, which causes the wrong one to be used.

It's even more of a problem with Plug'n'Play, since we inject the path to the binaries within the PATH (rather than always injecting the same node_modules/.bin folder). A similar problem then occurs where if you previously ran npm install -g babel-cli, then your execa scripts will use it instead of the local one.