Post

That's a very well thought out tradeoff. Suppose you have two dependencies: A@1.0.0 and B@1.0.0 both depending on C@^1.0.0. C introduces a feature in 1.1.0. A needed it very much, so it bumped C to ^1.1.0 and released 1.1.0 itself. Unfortunately, C 1.1.0 also introduced a bug that breaks B.

With Yarn, updating A to 1.1.0 will introduce two copies of C to your repository: 1.0.0 and 1.1.0. both A and B will continue to work, at the expense of having a duplicate dependency. You can then manually call `yarn dedupe` to get rid of the duplicate, leaving you with 1.1.0 only.

It is only then, after calling `yarn dedupe`, that will cause B to stop working. Then you can look at the situation and immediately deduct: "Before, I've had two copies of C. Once the package that originally requested C@^1.0.0 got C bumped (by deduplication) to 1.1.0, B stopped working".