Composer 使用别名.pdfVIP

Composer 使⽤别名 别名 为什么使⽤别名？ 当你使⽤ VCS 资源库，你将只会得到类似于这样的版本号：从分⽀发布的标签获 ，它看起来像 2.0 或 2.0.x。⽐较特殊的是，对于你的 master 分⽀，你会得到 ⼀个最新提交的 dev-master 版本。对于你的 bugfix 分⽀，你会得到⼀个最新提 交的 dev-bugfix 版本。以此类推，这些特殊的版本标识可以⽤来获 最新的分⽀ 源码。 如果你的 master 分⽀使⽤标签发布了 1.0 系列版本，即 1.0.1、1.0.2、1.0.3 等等，任何依赖它的资源包都可能会使⽤ 1.0.* 这个版本约束。 如果有⼈想要最新的 dev-master 版本，他们将会碰到⼀个问题：另⼀些依赖它的 包可能使⽤了 1.0.* 这个版本约束，因此在 require 这个开发版本时将会产⽣冲突， 因为 dev-master 不符合 1.0.* 的约束。 这时，就可以使⽤别名。 分⽀别名 dev-master 指向⼀个在你 VCS 项⽬上的主分⽀。有些⽤户会想要使⽤最新的开发 版本，这是相当常见的情况。因此，Composer 允许你别名你的 dev-master 版本为 ⼀个 1.0.x-dev 的版本号。这是通过在 composer.json ⽂件中的 extra 下指定 branch-alias 字段来完成的： { extra { branch-alias { dev-master 1.0.x-dev } } } 此处的分⽀版本必须以 dev- 开头 （不可⽐较的版本名称），对应的别名必须是可⽐ 较的开发版本名称 （即，以数字开头，并以 .x-dev 结束）。branch-alias 所引 ⽤的分⽀必须是存在的。对于 dev-master 你需要在 master 分⽀上提交它。 其结果是，任何⼈都可以使⽤ 1.0.* 版本约束来得到 dev-master 版本。 为了定义分⽀别名，你必须是需要别名的包的所有者。如果你想别名⼀个第三⽅包， ⽽又不想 fork 它到⾃⼰的版本库，可以使⽤⾏内别名，我们在接下来就会提到它。 使⽤⾏内别名 分⽀别名是⾮常适合⽤于主开发分⽀的。但为了使⽤它们，你需要拥有对源码的控制 权，并且你需要提交别名修改到你控制的版本库。 当你只想在本地项⽬中尝试⼀些依赖包的 bug 修正时，这并不是最好的⽅式。 出于这个原因，你可以在 require 和 require-dev 字段中直接别名你需要的包。 ⽐⽅说那你找到了 monolog/monolog 的⼀个 bug 。你在 GitHub 上克隆了 Monolog 并在名为 bugfix 的分⽀上修正了⼀个问题。现在你想安装这个版本到你的本地项 ⽬。 你所使⽤的 symfony/monolog-bundle require 了 monolog/monolog 并约束了版 本 1.*. 因此你需要让你的 dev-bugfix 满⾜该版本约束。 只要在你项⽬根⽬录的 composer.json ⽂件中加⼊以下内容： { repositories [ { type vcs, url https ///you/monolog } ], require { symfony/monolog-bundle 2.0, monolog/monolog dev-bugfix as 1.0.x-dev } } 它将会在你的 GitHub 上获 monolog/monolog 的 dev-bugfix 版本并将其版本 别名为 1.0.x-dev。 注意： 如果要对⼀个资源包使⽤⾏内别名，这个别名 （as 的右边）必 须能够使⽤版本约束。as 左边的部分在这之后将被丢弃。因此，如果 A 依赖 B ⽽ B 又依赖 monolog/monolog 且版本约束为 dev-bugfix as 1.0.x-dev，那么安装 A 时将使⽤ B 的版本约束，并识别为 1.0.x-dev，此时必须真实存在⼀个“分⽀别名”或“ 1.0 系列分⽀” 。否 则就必须在 A 的 comp