我想创建自己的包管理器，目前正在审查现有的解决方案。
我现在正在玩PHP的作曲家，它是相当令人惊讶的，它有两个文件:
-
composer.json用于项目配置，以及非固定依赖 -
composer.lock用于精确固定依赖
我确实理解为什么需要pin依赖关系，.lock信息本身对我来说似乎是合乎逻辑的。
我不明白的是为什么项目元数据被分成两个文件。
谁能解释一下，为什么它是这样设计的?为什么深度不能被固定在composer.json中?
乌利希期刊指南。原来，Rust的Cargo有相同的两个文件配置，并且对.lock文件的含义有很好的解释:http://doc.crates.io/guide.html#cargotoml-vs-cargolock
在开发期间，您通常希望能够轻松地升级到依赖项的最新兼容版本。composer.json有关于依赖项是什么以及哪些版本是兼容的信息。composer.lock缺乏兼容性信息，它可能会说包是根据依赖项的2.2.7版本构建的，但缺少关于版本>= 2.1和<其中3个依赖项是兼容的，而较低的版本则不兼容，下一个主要版本也不能保证是兼容的，所以请谨慎行事。>
另一方面，当为测试或发布而构建时，有必要确保每次都是针对完全相同的依赖版本集进行构建。composer.lock通过列出所使用的确切版本来实现这一点。即使出现了依赖的新版本，依赖绑定也可以确保构建不会更改，因此您不必担心依赖包的更改导致的行为更改。
.lock信息是绝对固定的，通常由基于json信息的composer update请求创建…但是开发人员并不一定想把所有的东西都固定在一个确切的版本上，如果没有.json文件，他们必须在每次升级依赖的版本时手动升级.lock文件。
.lock还保存了依赖项的依赖项，以及依赖项的依赖项，等等…而.json文件只保存直接依赖....作为一个开发者，你应该只需要控制你的直接依赖，并允许这些库通过他们自己的.json文件来控制他们自己的依赖
基本上，您应该根据json构建应用程序，但根据.lock部署