Put yarn into silent mode when calling nested yarn run commands

[sebmck]

Summary

This changes yarn run commands causing all child yarn processes to go into silent mode. This is useful as when you have a lot of nested scripts it can lead to a lot of stdout thrash with the yarn header CLI header and footer.

Before

yarn foo v0.26.0-0
$ echo foo && yarn bar
foo
yarn bar v0.24.3
$ echo bar
bar
✨  Done in 0.09s.
Done in 0.56s.

After

yarn foo v0.26.0-0
$ echo foo && yarn bar
foo
bar
Done in 0.56s.

Test plan

With a package.json of:

{
  "name": "yarn-silent-implicit",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "foo": "echo foo && yarn bar",
    "bar": "echo bar"
  }
}

produces the output of:

$ yarn foo
yarn foo v0.26.0-0
$ echo foo && yarn bar
foo
bar
Done in 0.56s.

Note that the the yarn bar call in the foo script does not include the yarn CLI header/footer.

[MalcolmDwyer]

This looks cleaner, but one counterpoint to this change is that it was useful to see when you were accidentally invoking a different version of yarn.

For example, my CI build uses frontend-maven-plugin to to install its own version of yarn, and then runs my 'yarn package' script from package.json. Like your example, my 'yarn build' called other yarn commands, and I noticed that the secondary yarn calls were being run not with my CI-installed yarn, but instead the one installed globally on the machine.

I realize there are other ways of fixing and working around that issue, but having the versions show up in the logs helped me discover the problem.

If there's some way to ensure that the nested yarn call is using the same yarn executable as the parent call, then I would see no issue with this change.

I hope this is worth discussing... Thanks

[bestander]

Thanks for raising the question. For sure worth discussing. Although I don't think that checking log lines is a robust solution for ensuring that you run the same yarn. Maybe forcing yarn binary location to the beginning of PATH would work better?

…

On Thu, 1 Jun 2017 at 20:01, Malcolm Dwyer ***@***.***> wrote: This looks cleaner, but one counterpoint to this change is that it was useful to see when you were accidentally invoking a different version of yarn. For example, my CI build uses frontend-maven-plugin to to install its own version of yarn, and then runs my 'yarn package' script from package.json. Like your example, my 'yarn build' called other yarn commands, and I noticed that the secondary yarn calls were being run not with my CI-installed yarn, but instead the one installed globally on the machine. I realize there are other ways of fixing and working around that issue, but having the versions show up in the logs helped me discover the problem. If there's some way to ensure that the nested yarn call is using the same yarn executable as the parent call, then I would see no issue with this change. I hope this is worth discussing... Thanks — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3536 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACBdWPXnQGPRXx_CLkNdhBy9DESU6bYNks5r_wqGgaJpZM4Nqngb> .

[edmorley]

Hi!

Unfortunately this has broken a number of workflows (#3671, #4423, #3767, guigrpa/oao#50), and as such I think we should consider reverting it for now, and later replacing it with a solution that suppresses just the header/footer output (ie versions and timing info) rather than the entire command output. For that I've opened #4615.

Nothing's ever straight-forwards is it! :-)

[bestander]

Thanks for raising, commenting in the new issue