你必须知道的 Composer 版本约束
37

file

如果你还不知道 composer,前往 composer 的主页然后开始阅读吧。

我曾见过许多人被他们使用的 composer 包之间依赖的约束问题所困扰。希望这篇文章能指出某些问题的原因,并提供避免这些问题的方法。我会从最糟的情景入手,并一步步改进约束。

全能的星号:*

Composer 有一个依赖解析器,所以它能够自动的找出我想要的,对吗?错。

* 声明一个版本约束可能是最糟糕的做法之一。因为你绝对无法控制你会得到什么。它可能是 任何 匹配 minimum-stability 和其它约束的版本。

基本上你就相当于在和 Composer 玩一个 俄罗斯轮盘赌 游戏,最终你会被它伤害到。然后你就可能会责怪这个工具太令你失望了。

如果你继续粗心大意,请最起码依赖最新的开发版本,通常被标记为 dev-master

写死的分支名称

所以你现在在使用 dev-master。问题在于,dev-master 所指向的代码可能会更改。至少,你获取的总是不稳定的包(从 composer 所表征的稳定性标志来看不稳定)。然而,更大的问题在于,dev-master 的意义可能随时会变。

比方说,现在它所表示的是最新的 1.0 开发版本。当开发者说他们要开始开发 1.1 版本的时候,dev-master 这个分支名字不再指向 1.0 分支,它开始指向最新的 1.1 开发分支。

除非你紧密关注着该库的开发,否则,直到你运行了 composer update 命令时,问题才会显示在你面前,然后毁了你一整天。因此,直接引用分支的名称并不是一个可持续的解决方案。幸运的是,在别名的问题上,composer 可以提供帮助。

分支别名

分支别名作为一个属性,包维护者可以将其放到他们的 composer.json 里面,允许这些分支名称映射到版本上。
像 1.0 , 2.1 等等分支名称并不是必须的, Composer 已经对这些进行了处理。

但是像 master 这样的分支名称会产生一个名为 dev-master 的版本,你一定要给它别名。 Composer 文档里面有 一个不错的关于别名的文章 ,里面解释了如何定义分支别名:

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

dev-master 版本会映射到一个 1.0.x-dev 的别名上,
这基本上意味着你可以用一个 1.0.*@dev 的约束来要求包。这样的好处是 1.0 的含义会被定义,且不会改变。 它也将使切换到稳定版本更容易。

分支别名的警告需要包维护者将它们放入。如果使用的是没有分支别名的库,则向它们发送一个上拉请求,将上面的 extra 部分添加到它们的 composer.json 中。

稳定版本

1.0.*@dev 这个约束已经很不错了。但问题是到目前为止,仍然还没有一个稳定的版本。除了你仍然运行着一个不稳定的版本这个事实之外,你的代码并没有什么问题。

但是如果别人的项目依赖了你的包,那么你的用户需要明确地使用 @dev 标识来允许 Composer 安装不稳定的版本,或者干脆降低项目 minimum-stability 的等级,这意味着他们将获得 所有依赖包 的不稳定版本。

避免开发版本不稳定性的最好方法就是打上 release 标签(指发布稳定版本)。 如果你正在使用一个没有打上 release 标签的库,提醒它的维护者直到打上标签。现在就做!

作为 Composer 社区的一份子,我们要有责任心。 我们必须发布稳定的版本,并且应该维护好 CHANGELOG (更新日志)。 这很不容易,但是这将让整个生态系统发生巨大的改变。记住,如实地、 语义化 地来打标签。

当你发布了一个稳定的版本, 你就能去掉 @dev 标识并且将你的约束改为 1.0.*

下一个重大版本

如果你所依赖的包的每一个发布节点都坚持遵守语义化版本的规则,并且严格向后兼容,那么你就可以逐渐提高约束。

现在 1.0.* 版本有一些潜在的兼容性问题,并很快发布了 1.1 版本。如果你的约束是 1.0 ,但是别人需要 1.1 版本的新特性(还记得向后兼容吗?), 他们就不能安装 1.1 版本。所以你需要重写你的约束,比如: 1.*

好极了,除非你开始依赖 1.1 版本的新特性,否则你不必修改约束,它将会仍然匹配 1.0 这个没有新特性的版本。

接着,你修改约束为 >=1.1,<2.0 ,但这种写法比较麻烦。使用波浪线操作符能允许你用简洁的方式表示上面的表达式: ~1.1 。这表示任意在 1.1 以上的 1.* 版本。现在你知道了,鼓励语义化版本是为了使用波浪线操作符,并且可以最大化的封装兼容性。

TLDR


Practice makes perfect.

原文地址:https://igor.io/2013/01/07/composer-vers...

译文地址:https://laravel-china.org/topics/10807/t...

本帖已被设为精华帖!
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!