@@ -117,17 +117,15 @@ If the `package.json` contains a range, and a new in-range version is released t
The upside is that the lockfile will hold back `foobar` to `1.1.0` unless it's forced to upgrade, so the break is postponed. The downside is _how_ you will discover the break eventually.
The easiest case is if you for some reason _need_ to upgrade `foobar`, e.g. for a new feature it contains, so you migth run something like `yarn upgrade foobar` to update the lockfile and either discover the break during your development or when you push your new development to CI for testing. In this case, hopefully you'll guess it's `foobar` that broke it and not your own code.
The easiest case is if for some reason you _need_ to upgrade `foobar`, e.g. for a new feature it contains, so you might run something like `yarn upgrade foobar`. Then you might either discover the break during your development or when you push your new development to CI for testing. In this case, hopefully you'll guess it's `foobar` that broke it and not your own code.
Alternatively, maybe someone thinks "This lockfile is probably really out of date and might be missing some essential patches" and decides to `yarn upgrade` the whole thing in one go. No doubt the diff will be full of green and red as many direct and indirect dependencies will have changed versions. Then it's pushed to CI for testing, fails, and you have to guess which of the changes caused it until you hit on `foobar`. Perhaps by manually looking through the lock file diffs line by line if you're unlucky and it's not obvious. Maybe dep `blahblah` also broke, to make it even harder.
Alternatively, maybe someone thinks "This lockfile is probably really out of date and might be missing some essential patches" and decides to `yarn upgrade` the whole thing in one go. No doubt the diff will be full of green and red as many direct and indirect dependencies will have changed versions. Then it's pushed to CI for testing, fails, and you have to guess which of the changes caused it until you eventually narrow it down to `foobar`. This might require even manually looking through the lock file diffs line by line. Maybe dep `blahblah` also broke at teh same time, to make it even harder.
By ceding control of direct dependency versions to the lock file, you have lost the ability to _know_ when things are updated. You also may be missing out on really important patches you're not even aware of, because they're "in range" yet locked back to vulnerable or buggy versions in the lock file.
Further, there's no obvious reason or driver for when _any_
Reconsider the same scenario if `foobar` had instead been pinned to `1.1.0` in `package.json` The (broken) upgrade to `1.2.0` would have been explicitly proposed to you via a Renovate PR, you would see the break, and know that the version is bad. Meanwhile you could be upgrading all the other essential fixes of other dependencies without worrying about `foobar`. You could even be running `yarn upgrade` regularly to be getting _indirect_ package updates in the lockfile and seeing if everything still passes.
Once again, think if instead `foobar` had been pinned to `1.1.0` in addition to the lockfile. The (broken) upgrade to `1.2.0` would have been explicitly proposed to you via a Renovate PR, you would see the break, and know that the version is bad. Meanwhile you could be upgrading all the other essential fixes of other dependencies without worrying about `foobar`. You could even be running `yarn upgrade` regularly to be getting _indirect_ package updates in the lockfile and seeing if everything still passes.
Essentially, the lock file does not solve the same semver problems that pinning solves - but it compliments it. For this reason our usual recommendation using a lock file regardless of whether you pin dependencies or not, and pinning even if you have a lock file.
Therefore, the lock file does not solve the same semver problems that pinning solves - but it compliments it. For this reason our usual recommendation using a lock file regardless of whether you pin dependencies or not, and pinning even if you have a lock file.
Don't forget though that our motto is "Flexible, so you don't need to be", so go ahead and configure however you want. Also, we're open to ideas for how to make lock file updates more "visible" too. e.g. are you interested in a Renovate feature where you get a lockfile-only PR any time a direct dependency gets an in-range update?
