Make "yarn outdated" exit with a non-zero exit code when there are outdated dependencies

[ivan-kolmychek]

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

Feature (probably).

What is the current behavior?

With outdated packages present, yarn outdated exits with 0

The npm outdated in the same situation will exit with 1 (as of NPM 4.2.0).

What is the expected behavior?

With outdated packages present, yarn outdated should exit with non-zero exit code.

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

OS: Debian Jessie inside the Docker, library/node image, 7.10 tag.
Node: v7.10.0
Yarn: 0.24.4

P.S.
Bundlers bundle outdated also returns non-zero exit code if outdated gems are present, just for the reference.
We use that part of behavior of both Bundler and NPM in automated checks on CI.

[bestander]

Sounds reasonable, send a PR

[wssgcg1213]

I think it unreasonable.... same with npm outd
my code is like this, the feature break my cli and throw an err

spawn('yarn', ['outdated']).on('close', (code) => {
  if (code > 0) { 
    reject(); 
  }  else {
    resolve();
  }
}

[vincentmigot]

I agreed with the previous comment because having outdated library can be just normal.
You may have requirement on library version (example using angular with the typescript version) so you just can't update them to the latest version or at least not right now.
But with this non zero exit status you can't use this feature in a CI environment any more --> All builds failed unless you remove call to yarn outdated.
So you can't track regularly if there are new version of your libraries automatically and updated them based on your needs OR NOT !
That was really a bad idea.

[ivan-kolmychek]

Replied in #7573, let me copy in here too, as it may be relevant for the future discussions on this:

Well, I created the #3483 because in some cases it makes sense to treat yarn outdated as critical check. But I do agree that it's not always the case. +1

From my perspective, either flag to exit with 0 when there are outdated packages or a flag to exit with 1 in that case would solve the problem.

I personally would prefer having to specify an extra flag to show that I want to treat outdated packages as normal situation, in part because then the default behavior lines up with how npm outdated behaves. But that's my personal preference, and as long as there is a way to say "please exit with non-zero status code when there are outdated packages" I don't really care that much what is default behaviour.