Add `--silent` flag to CLI run command

[pgrippi]

Do you want to request a feature or report a bug?

feature

What is the current behavior?

I use the npm test command in my ember cli projects to run my tests. I was happy to see that yarn test works the same way as npm test but it's missing one feature that I use: the --silent flag.

When I run yarn test --silent (or yarn run test --silent) it prints out the yarn version and command it runs:

$ yarn run test --silent
yarn run v0.15.1
$ ember test
...

What is the expected behavior?

I would expect that when I run yarn run <cmd> --silent it would suppress the output of the yarn version and the command it is running, similar to how npm run --silent works.

Please mention your node.js, yarn and operating system version.

Node: v4.6.0
Yarn: v0.15.1
OS: MacOS Sierra 10.12.0

[FLGMwt]

Talked a bit with @cpojer on discord about exactly how silent something like this should be and he convinced me at least that this might not be a necessary thing for a cli to provide. Nothing that I could think of can't be handled by a >/dev/null 2>&1 if you really don't care about the output.

Counterpoints?

[pgrippi]

Ah, but I do care about the output. My use case here is that I'm running the test on a CI server and the output is an xml file. My command looks something like this:

yarn test --silent -- --other-args > junit.xml

Since yarn prints out the version and command the xml file generated by my test script has that in it before the xml output and I'm left with an invalid xml file.

[jfeltesse]

Also, terminal colors mess up the output when doing deploys here. Maybe it's something that should be addressed in the way my deploys are done but a simple --silent flag would avoid stuff like:

[2K�[1G�[1myarn install v0.15.1�[22m
�[2K�[1G�[90m[1/4]�[39m Resolving packages...
�[2K�[1G�[2K�[1G�[2K�[1G�[90m[2/4]�[39m Fetching packages...
�[2K�[1G�[1G 0/790�[1G 5/790�[1G 226/790�[1G 745/790�[2K�[1G�[2K�[1G�[33mwarning�[39m fsevents@1.0.14: The platform "linux" is incompatible with this module.
�[2K�[1G�[34minfo�[39m "fsevents@1.0.14" is an optional dependency and failed compatibility check. Excluding it from installation.
�[2K�[1G�[90m[3/4]�[39m Linking dependencies...
�[2K�[1G�[33mwarning�[39m Unmet peer dependency "cheerio@0.19.x || 0.20.x || 0.22.x".
�[2K�[1G�[1G 0/32�[2K�[1G�[1G 0/2095�[1G 131/2095�[1G 332/2095�[1G 524/2095�[1G 759/2095�[1G 976/2095�[1G 1229/2095�[1G 1493/2095�[1G 1733/2095�[1G 1877/2095�[1G 2031/2095�[2K�[1G�[2K�[1G�[1G 0/32�[2K�[1G�[2K�[1G�[90m[4/4]�[39m Building fresh packages...
�[2K�[1G
�[2K�[1G
�[2K�[1G
�[2K�[1G
�[2K�[1G�[1G�[1A�[2K�[1G�[1B�[1G�[2A�[2K�[1G�[2B�[1G�[3A�[2K�[1G�[3B�[1G�[4A�[2K�[1G�[4B�[1G�[4A�[2K�[4B�[1G�[3A�[2K�[3B�[1G�[2A�[2K�[2B�[1G�[1A�[2K�[1B�[2K�[1G�[4A�[2K�[1G�[32msuccess�[39m Saved lockfile.
�[2K�[1GDone in 2.64s.

With npm you can do npm install --progress false --color false to ease things a bit.

[jacott]

If stdout is not connected to a terminal then it should not use any control characters; just like npm does

[chrisvasz]

We would love to see this on many more of the yarn commands -- install, upgrade, and outdated come to mind. We use a bunch of private, internal modules, and to determine whether they are up-to-date, we run npm/yarn outdated on each module inside our modules folder. npm outdated outputs nothing if there are no outdated package dependencies, so with npm, the output of our recursive outdated command looks like this (simplified):

/modules/button
/modules/sortable-list
Package             Current  Wanted  Latest  Location
react-sortable-hoc   0.0.11  0.0.11   0.1.0  sortable-list
/modules/tabs
/modules/textbox
/modules/tooltip

The equivalent output in yarn looks like this:

/modules/button
yarn outdated v0.16.1
Done in 0.30s.
/modules/sortable-list
yarn outdated v0.16.1
Package            Current Wanted Latest
react-sortable-hoc 0.0.11  0.0.11 0.1.0
Done in 0.41s.
/modules/tabs
yarn outdated v0.16.1
Done in 0.32s.
/modules/textbox
yarn outdated v0.16.1
Done in 0.37s.
/modules/tooltip
yarn outdated v0.16.1
Done in 0.20s.

The signal/noise ratio in the second example is much lower. We most definitely care about relevant output (in this case, outdated packages), and a way to silence the surrounding yarn front- and back-matter would be really helpful.

[minasmart]

I found a really terrible way to work around this:

"scripts": {
  "command-that-captures-output": "cat $(yarn run command-that-yields-output 2>&1 >/dev/null)",
  "command-that-yields-output": ">&2 echo ./path-to-a-file-we-care-about"
}

The order of redirects is really important here. For command-that-yields-output, I'm sticking the output I care about in stderr, then in command-that-captures-output, I'm pointing stderr to the tty that stdout is currently connected to, I'm then pointing stdout to /dev/null. This results in stderr going to the tty that cat is connected to, and silencing the builtin yarn output.

Hope this helps!

[arxpoetica]

Status on this? When using Yarn for build scripts, it gets really noisy really fast. This is what happens when I run multiple scripts through watchers:

And I'm just getting started. Every time I change a watched file, it reruns the yarn command with a bunch of output that makes it hard to read the stuff I care about—all the non-yarn output.

Update I see that it's being worked on in #2420 w00t!

[joscha]

fixed in #2420