yarn run --silent doesn't suppress yarn's stderr

[zevdg]

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

bug

What is the current behavior?
yarn run --silent doesn't suppress stderr

If the current behavior is a bug, please provide the steps to reproduce.

for example, imagine this script section of a package.json file

"scripts": {
    "git-is-clean": "git diff-index --exit-code --shortstat --line-prefix 'UNCOMMITED CHANGES!' HEAD --",
    "deploy": "yarn run --silent git-is-clean && firebase deploy"
  },

If the working directory is not clean, the output of yarn run deploy would be

yarn run v1.3.2
$ yarn run --silent git-is-clean && firebase deploy
UNCOMMITED CHANGES! 2 files changed, 150 insertions(+), 7 deletions(-)
error Command failed with exit code 1.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Note the duplicated error Command failed with exit code 1.
Every level of nesting that fails will add one of these lines.
If the output showed which command failed, I could sorta see this being a feature and not a bug.
For example

...
error Command "git-is-clean" failed with exit code 1.
error Command "deploy-staging" failed with exit code 1.
...

But as is, it's just clutter.

What is the expected behavior?
If the working directory is not clean, the output of yarn run deploy should be

yarn run v1.3.2
$ yarn run -s git-is-clean && firebase use dev && firebase deploy --message "$(git log -1 --oneline --decorate=short)" #--decorate-refs-exclude=HEAD
UNCOMMITED CHANGES! 2 files changed, 150 insertions(+), 7 deletions(-)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Workarounds
FWIW, npm --silent does squelch stderr as expected, so i can "solve" this problem by using npm run --silent instead of yarn run --silent inside my scripts, but it feels dirty to have yarn call npm.
Alternatively, in some cases, I could do yarn run --silent foo 2>/dev/null, but that would hide stderr from the foo script output so it isn't always an option.

Please mention your node.js, yarn and operating system version.
yarn v1.3.2
node v8.9.4
os Solus 3 - linux 4.14.18

[hulkish]

@zevdg Why would you want to hide errors? Isn't the real solution here to handle the errors in your script?

[zevdg]

Why would you want to hide errors?

Did you fully read the initial description? I thought there was enough information there to answer this question, but I can try to articulate it more clearly.

First off, I'm not suggesting that ALL of the error output should be hidden. Simply the commands (generally sub-commands) run with the --silent flag. Because output like

error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.

is redundant and unhelpful. I hope we can agree on that much. Imagine you have a script "foo" which calls a script "bar" which calls a script "baz" which calls a script "qux". If qux fails, I would get the output above. Ideally, i'd want something like

error Command "qux" failed with exit code 1.
error Command "baz" failed with exit code 1.
error Command "bar" failed with exit code 1.
error Command "foo" failed with exit code 1.

but barring that enhancement, I'll settle for a single

error Command failed with exit code 1.

output from yarn itself and then I'd modify my scripts to log their own failures more verbosely. In npm, this can be easily achieved by using the --silent flag when calling one script from another script, but in yarn, the silent flag doesn't work the same way. In yarn, there is no good way to achieve this.

Isn't the real solution here to handle the errors in your script?

I'm not sure what you're even suggesting by this. Could you please give me a concrete example.
Please use the example given in the original description (repeated here)

"scripts": {
    "git-is-clean": "git diff-index --exit-code --shortstat --line-prefix 'UNCOMMITED CHANGES!' HEAD --",
    "deploy": "yarn run --silent git-is-clean && firebase deploy"
  },

How do you suggest I change these 2 scripts to "handle the errors". The whole point of the "git-is-clean" script is to fail when there are uncommitted changes. It is a helper script that is meant to be called by other yarn scripts to prevent them from being executed on an "unclean" working directory. I see no good way for it to do that without getting the useless duplicate error output from yarn.

[hulkish]

@zevdg This makes more sense, i overlooked the focus on redundancy. Ok you win. have a 🌮

[Wilfred]

As mentioned in #5440, this is a common use case when you have a linter or test runner command specified in your package.json. These commands return non-zero exit codes when you're working on the code, and you don't need yarn to report anything else.

[IanEdington]

I am also experiencing this with eslint fix. I use no-inline-config so that it will fixes fixable errors whenever possible.

[charmsRace]

@Wilfred you can get around this by doing something really hacky like "test": "ava || exit 0". Of course this breaks down if you want to pass flags, which you pretty much always want to be able to do.

I'd really like a way to trigger --silent in the script definition, although I don't know if that's especially feasible. Since I know you can make a .yarnrc containing

--install.frozen-lockfile true,

I tried something like

--test.silent true,

but since it's broken anyway, it's difficult to tell whether you can attach flags to secondary commands (i.e. ones that are short for yarn run ____).

[dawnmist]

I would especially like to be able to suppress yarn's echoing of the original command to stderr when an error occurs. In particular for use in CI/CD situations where a deployment target requires logging into the upstream server, as at present yarn echoes the values of the username and password fields (set via env variables) to the error output. Sending stderr to /dev/null means that you also miss the 'Invalid login' message.

$ yarn --silent exp:login
02:03:13 [exp] Invalid username/password. Please try again.
error An unexpected error occurred: "Command failed.                                                                                                           
Exit code: 1
Command: sh
Arguments: -c /projectDir/node_modules/.bin/exp login -u username -p XXXXXXXX --config ./app.json
Directory: /projectDir
Output:
".
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c yarn --silent exp login -u ${EXPO_USER} -p ${EXPO_PW} --config \"./app.json\"
Directory: /projectDir
Output:
".

Out of the above, the only message that should be coming back is the [exp] Invalid username/password. Please try again line. The following section has yarn explicitly listing the exact username and password (I've replaced username/password values above) in the Arguments section that was used - which is awful for CI/CD logging. Trying to suppress yarn's leaking of credentials results in also losing the Invalid username/password message since both are written to stderr.

[alecmev]

@dawnmist I believe that the excessively long output you're seeing is due to the now-fixed #5457. The fix came out with 1.6.0, give it a go. But yeah, --silent is still not silent.

[andreas-ateles]

This is also affecting yarn workspace run, yarn v1.13.0. (In which case it might not even be possible to run npm instead.)

$> yarn workspace project run --silent prettier:check
src/some/file.js
src/some/file.css
error Command failed with exit code 1.
error Command failed.
Exit code: 1
Command: /usr/local/bin/node
Arguments: /opt/yarn-v1.13.0/lib/cli.js --silent run prettier:check
Directory: /app/packages/project
Output:

$>

This is very verbose and confusing for users when yarn run is used in tooling.
(And seems to be no way to redirect the yarn spam to /dev/null and keep the listed files (the original commands output), as both are printed to STDOUT.)

[kaste]

I made a minimal patch in #7472 🤷‍♂

I'm actually coming from #5440 so my perspective is that a yarn run --silent eslint . should have just the same outcome (stdout, stderr, exitcode) as a plain eslint .. Implementing a fancier Command 'x' failed for non-silent mode was not my issue; would surely look nice though.