是否应该定期删除yarn.lock文件，以使yarn从package.json中指定的semver范围内安装最新版本的依赖项和子依赖项？ package-lock.json和npm也有同样的问题。
我问的原因是我过去曾在一个项目中工作，该项目的某些依赖项设置为非常旧的版本。团队（正确或错误）将其视为更新当前版本之后的两个主要版本的依赖项是一项冒险更改。因此，我想使依赖项保持最新状态，并避免重大的依赖项更新。
我的团队使用git-flow分支模型（https://nvie.com/posts/a-successful-git-branching-model/）。因此，我想知道在每个发行版合并到master分支之后，是否适合在我们的development分支中启动新yarn.lock。
编辑：
如@str所指出的，我原来的措词（上面未作改动）有点不一致。
我前后矛盾的部分是，我要获得一个semver范围内的最新版本，但随后我举了一个例子，说明我在一个“落后两个主要版本”的项目中工作。
确实，根据我的经验，最常用的semver range运算符将不允许yarn或npm安装一个主要值高于range表达式中版本的版本。例如，如果您使用https://semver.npmjs.com/上的npm semver计算器并输入lodash包和^ 2.0.0范围，则它将仅与2.x.x版本匹配。
但是，可以指定包含主要版本更新的semver范围。如果您转到https://semver.npmjs.com/并输入lodash软件包，并且输入范围> 2，则会看到该范围与所有3.x.x版本和所有4.x.x版本匹配。
无论如何，我要问的问题更多是关于允许依赖关系总体更新，而不是允许依赖关系更新到较新的主要版本的特定情况。关于落后于两个主要版本的示例是我尝试参考的情况，即更新依赖项开始似乎有风险，因此团队开始将其推迟。
在我看来，yarn.lock或package-lock.json在短期内很有用，因为它可以使项目在不同机器上更一致地构建，并且从长远来看也很有用，因为它允许团队检查进行历史修订，并使其与创建时相同。但我也认为，对于项目而言，定期删除锁是一个好习惯，以便所有依赖项都可以更新到其存储范围内的最新版本。有没有人有过这样的经验，可以在这里发表评论？还是有人可以告诉我一个令人信服的理由，为什么这将是一个坏主意？