|
| 1 | +- Start Date: 2017-03-18 |
| 2 | +- RFC PR: (leave this empty) |
| 3 | +- Yarn Issue: (leave this empty) |
| 4 | + |
| 5 | +# Summary |
| 6 | + |
| 7 | +This RFC proposes the addition of a "--transitive" flag to `yarn upgrade-dependencies`. |
| 8 | + |
| 9 | +This will allow developers to choose from and upgrade transitive dependencies listed in the yarn.lock file. |
| 10 | + |
| 11 | +# Motivation |
| 12 | + |
| 13 | +It is occasionally necessary to upgrade versions of transitive dependencies in an application (in the case of security patches or critical bug fixes) without going through the regular workflow. Currently, to upgrade transitive dependencies, a developer would have to hand edit the yarn.lock file (which is an anti-pattern; reasons as to why this must not be done are outside the scope of this RFC). |
| 14 | + |
| 15 | +Consider the dependency graph A->B->C. (A is an application that lists B in its package.json; B lists C in its package.json.) The regular workflow would be to bump the minimum required version of C in B, and bump the new minimum required version of B in A. |
| 16 | + |
| 17 | +This causes friction however when B is not already at the latest version in A, and is sufficiently large that upgrading to a new version of B in A is non-trivial. |
| 18 | + |
| 19 | +By allowing the upgrading of transitive dependencies listed in the lockfile, bug fixes and security patches can be rolled out quicker. |
| 20 | + |
| 21 | +# Detailed design |
| 22 | + |
| 23 | +*** (I am still scoping this out; any help here would be appreciated!) *** |
| 24 | + |
| 25 | +TODO |
| 26 | + |
| 27 | +# How We Teach This |
| 28 | + |
| 29 | +The Yarn CLI should add a `--transitive` to the output of `yarn upgrade-interactive --help`, explaining that this will list all dependencies, including transitive dependencies in the list. |
| 30 | + |
| 31 | +Yarn should use the term "transitive" to describe the sub-dependencies as this is a mathematically accurate description, and more precise than "sub-dependencies" or "additional dependencies". (npm uses this term (http://blog.npmjs.org/post/145724408060/dealing-with-problematic-dependencies-in-a). |
| 32 | + |
| 33 | +The new feature: |
| 34 | +- is a relatively minor addition of functionality; the documentation will need amending to describe the new flag. |
| 35 | +- does not change other existing functionality of Yarn, and would not require existing users to change their workflow in any way. |
| 36 | +- should be taught via release notes and a blog post at time of release. The documentation and `--help` output will serve as a reference for future users. |
| 37 | + |
| 38 | +# Drawbacks |
| 39 | + |
| 40 | +It is preferred to handle these situations via the "regular workflow" as described in the motivation section above. Introducing this as an additional workflow could confuse or engender bad practices. The documentation of the flag should be written with care to reduce this as a possibility. |
| 41 | + |
| 42 | +If the yarn.lock file has to be regenerated, the presumably critical information of the minimum version of the transitive dependency could be lost. |
| 43 | + |
| 44 | +# Alternatives |
| 45 | + |
| 46 | +Users could continue to update transitive dependencies via the 'regular' workflow. |
| 47 | + |
| 48 | +TODO |
| 49 | + |
| 50 | +# Unresolved questions |
| 51 | + |
| 52 | +Is there a possibility of introducing transitive dependency version conflicts that cannot be resolved? |
| 53 | + |
| 54 | +TODO |
0 commit comments