2016-09-10 18:02
浏览 357


I want to create my own package manager, and currently reviewing existing solutions.

I'm playing with PHP's Composer now, and it was quite surprising that it has two files:

  • composer.json for project configuration, and non-pinned dependencies

  • composer.lock for exact pinned dependencies

I do understand why one needs to pin dependencies, .lock information by itself seems logical to me.

What I do not understand is why project metadata was split into two files.

Can anyone explain, why it was designed this way? Why deps could not be pinned right in the composer.json?

UPD. Turns out, Rust's Cargo has the same two file configuration in place, and has a nice explanation of the meaning of the .lock file:

图片转代码服务由CSDN问答提供 功能建议



  • 用于项目配置的 composer.json 和用于精确固定依赖关系的非固定依赖关系

  • composer.lock / p>

    我理解为什么需要引入依赖关系, .lock 信息本身对我来说似乎是合乎逻辑的。


    任何人都可以解释,为什么它是这样设计的? 为什么deps无法固定在 composer.json 中?

    UPD。 事实证明,Rust的Cargo具有相同的两个文件配置,并且对 .lock 文件的含义有一个很好的解释:

  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • dongyiyu3953 2016-09-10 18:08

    .lock information is absolutely pinned, typically created by a composer update request based on the json information... but developers don't necessarily want to pin everything to an exact version, and without that .json file they have to upgrade the .lock file manually for every version upgrade of their dependencies.

    The .lock also holds dependencies of dependencies, and dependencies of dependencies of dependencies, etc... whereas the .json file only holds immediate dependencies.... and as a developer, you should only need to control your immediate dependencies, and allow those libraries to control their own dependencies via their own .json files

    Basically, you should build your application against the json but deploy against the .lock

    解决 无用
    打赏 举报
  • douque9815 2016-09-10 18:10

    During development, you usually want to be able to upgrade to the latest compatible version of dependencies easily. composer.json has the information on what the dependencies are and which versions are compatible. composer.lock lacks the compatibility information, it may say that the package was built against version 2.2.7 of a dependency but information is missing about rules such as that versions >= 2.1 and < 3 of that dependency are compatible while lower versions aren't and the next major version isn't guaranteed to be so play it safe.

    When building for testing or release, on the other hand, it's necessary to make sure you build against the exact same set of dependency versions every time. composer.lock allows that by listing out the exact versions used. Even if new versions of dependencies come out, the dependency pinning insures that the build won't change so you won't have to worry about changes in behavior caused by changes in dependency packages.

    解决 无用
    打赏 举报

相关推荐 更多相似问题