Is it appropriate to periodically delete the yarn.lock file to allow yarn to install the latest versions of dependencies and subdependencies from within the semver ranges specified in package.json? The same question goes for package-lock.json and npm.
The reason I ask is that I have worked on a project in the past where some dependencies were set to very old versions. The team (rightly or wrongly) perceived it as a risky change to update a dependency that was two major versions behind the current version. So I want to keep dependencies fairly up to date and avoid big-bang dependency updates.
My team uses the git-flow branching model (https://nvie.com/posts/a-successful-git-branching-model/). So I am wondering whether it would be appropriate for us to start a new yarn.lock in our develop branch after each release is merged to the master branch.
EDIT:
As pointed out by @str, my original phrasing (unchanged above) was a bit inconsistent.
The part where I was inconsistent was that I was asking about getting the most up to date version within a semver range but then I gave an example where I worked on a project that was "two major versions behind".
It is indeed true that the semver range operators that are most commonly used (in my experience) will not allow yarn or npm to install a version that has the major value higher than the version in the range expression. For example if you use the npm semver calculator at https://semver.npmjs.com/ and enter package lodash and range ^2.0.0 it will only match the 2.x.x versions.
However, it is possible to specify a semver range that includes major version updates. If you go to https://semver.npmjs.com/ and enter package lodash and range >2 you will see that this range matches all the 3.x.x versions and all the 4.x.x versions.
Anyway, the question that I was intending to ask was more about allowing dependencies to update in general than the specific case of allowing them to update to a newer major version. The example about being two major versions behind was my attempt to refer to a situation where updating the dependencies starts to seem risky so the team starts putting it off further.
It seems to me like a yarn.lock or package-lock.json is useful in the short term because it makes the project build more consistently across different machines, and also useful in the long term because it allows the team to check out a historic revision and build it the same as it was built when it was created. But I also think it could be a good practice for a project to periodically have the lock removed so that all of the dependencies can update to the latest versions within their semver ranges. Has anyone got experience with such a procedure that they could comment on here? Or could anyone tell me a compelling reason why it would be a bad idea?