Enhancement: make deprecated sub-package warnings more informative

[BYK]

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

What is the current behavior?
Currently, when installing a package (p1) that depends on a deprecated package (p2), yarn just says version X of p2 is deprecated in a warning.

What is the expected behavior?
The desired behavior is to tell the user what exactly uses the deprecated version of p2 and possibly offer an upgrade for the package p1.

[ghost]

Upvoted as this issue seems it would benefit security beyond current package introspection made available in the Yarn CLI today.

Context. This feels important to me based on my experience monitoring the security of dependencies used in the React Native Webpack Starter Kit over more than a year, of which more than 1,000 dependencies were monitored. And though the kit was deprecated before Yarn was introduced to it I feel comforted knowing plans to give individuals more actionable insight and understanding as to what it means to build with tools like React and Webpack will add value.

[onurtemizkan]

In current version, when there is a deprecated sub-dependency, dependency path is shown in the warning message:

➜ yarn add eslint@0.1.0
yarn add v0.27.5
[1/4] Resolving packages...
warning eslint > jshint > minimatch@0.4.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
...

But the message doesn't indicate that it is a deprecation warning.
Also, it may still be unclear what A > B > .. > X stands for; if the 'deprecated sub-dependency' information is not explicitly indicated in the message.

[BYK]

@jhabdas @dmbdesignpdx @wtgtybhertgeghgtwtg @gaearon thoughts?

[ghost]

Initial thought is to create an enumerable list of valid notification types and expose an API to package maintainers so they may list a reason code for the notification, e.g.

warn [infosec] vulnerability detected in ...

info [compat] kernel not supported in ...

Defaulting to "[general]" for explicitness if left unspecified.

[dmbdesignpdx]

Maybe it's something as simple as taking the information that's provided in the current warning and making it more human friendly?

current:

warning A > B > C > D > X@0.0.1: Please update to X 0.1.0 or higher to avoid an explosion.

to something along the lines of:

warning D uses a deprecated version of X: 0.0.1 being used -- 0.1.0 wanted to avoid an explosion.

The wording can totally be changed as per @jhabdas suggestions; i.e. the security issue:

warning D uses an at-risk version of X ...

and the reason:

... 0.1.0 wanted due to a vulnerability detected ...

[BYK]

@jhabdas I think your suggestion is pretty great but it is also out of scope for this tiny ticket. Would you like to submit an RFC for that since it sounds like a larger effort with some spec-work required in it?

[ghost]

@BYK done - yarnpkg/rfcs#72