Composer 资源库

fork 的第三方库。如果你在项目中使用某些库，并且你决定改变这些库内的某些东西，你会希望你项目中使用的是你自己的修正版本。如果这个库是在 GitHub 上（这种情况经常出现），你可以简单的 fork 它并 push 你的变更到这个 fork 里。在这之后你更新项目的 composer.json 文件，添加你的 fork 作为一个资源库，变更版本约束来指向你的自定义分支。关于版本约束的命名约定请查看 库（资源包）。例如，假设你 fork 了 monolog，在 bugfix 分支修复了一个 bug：{ "repositories": [ { "type": "vcs", "url": "https://github.com/igorw/monolog" } ], "require": { "monolog/monolog": "dev-bugfix" }}当你运行 php composer.phar update 时，你应该得到你修改的版本，而不是 packagist.org 上的 monolog/monolog。注意，你不应该对包进行重命名，除非你真的打算摆脱原来的包，并长期的使用你自己的 fork。这样 Composer 就会正确获取你的包了。如果你确定要重命名这个包，你应该在默认分支（通常是 master 分支）上操作，而不是特性分支，因为包的名字取自默认分支。如果其它包依赖你 fork 的这个分支，可能要对它做版本号的行内别名设置，才能够准确的识别版本约束。更多相关信息请查看 别名。使用私有资源库完全相同的解决方案，也可以让你使用你 GitHub 和 BitBucket 上的私人代码库进行工作：{ "require": { "vendor/my-private-repo": "dev-master" }, "repositories": [ { "type": "vcs", "url": "git@bitbucket.org:vendor/my-private-repo.git" } ]}唯一的要求是为一个 git 客户端安装 SSH 秘钥。Git 的备选方案Git 并不是 VCS 资源库唯一支持的版本管理系统。以下几种都是被支持的：Git: git-scm.comSubversion: subversion.apache.orgMercurial: mercurial.selenic.com为了从这些系统获取资源包，你必须安装对应的客户端，这可能是不方便的。基于这个原因，这里提供了 GitHub 和 BitBucket 的 API 的特殊支持，以便在无需安装版本控制系统的情况下获取资源包。在 VCS 资源库提供的 dist 中获取 zip 存档。GitHub: github.com (Git)BitBucket: bitbucket.org (Git and Mercurial)VCS 驱动将基于 URL 自动检测版本库类型。但如果可能，你需要明确的指定一个 git、svn 或 hg 作为资源库类型，而不是 vcs。If you set the no-api key to true on a github repository it will clone the repository as it would with any other git repository instead of using the GitHub API. But unlike using the git driver directly, composer will still attempt to use github's zip files.Subversion 选项由于 Subversion 没有原生的分支和标签的概念，Composer 假设在默认情况下该代码位于 $url/trunk、$url/branches 和 $url/tags 内。如果你的存储库使用了不同的布局，你可以更改这些值。例如，如果你使用大写的名称，你可以像这样配置资源库：{ "repositories": [ { "type": "vcs", "url": "http://svn.example.org/projectA/", "trunk-path": "Trunk", "branches-path": "Branches", "tags-path": "Tags" } ]}如果你的存储库目录中没有任何分支或标签文件夹，你可以将 branches-path 或 tags-path 设置为 false。如果是一个位于子目录的包，例如， /trunk/foo/bar/composer.json 和 /tags/1.0/foo/bar/composer.json，那么你可以让 composer 通过 "package-path" 选项设置的子目录进行访问，在这个例子中可以将其设置为 "package-path": "foo/bar/"。PEARpear 类型资源库，使得从任何 PEAR 渠道安装资源包成为可能。Composer 将为所有此类型的包增加前缀（类似于 pear-{渠道名称}/）以避免冲突。而在之后使用别名时也增加前缀（如 pear-{渠道别名}/）。例如使用 pear2.php.net：{ "repositories": [ { "type": "pear", "url": "http://pear2.php.net" } ], "require": { "pear-pear2.php.net/PEAR2_Text_Markdown": "*", "pear-pear2/PEAR2_HTTP_Request": "*" }}在这种情况下渠道的简称（别名）是 pear2，因此 PEAR2_HTTP_Request 包的名称应该写作 pear-pear2/PEAR2_HTTP_Request。注意： pear 类型的资源库对每个 requires 都要做完整的请求，因此可能大大降低安装速度。自定义供应商别名通过自定义供应商名称，对 PEAR 渠道包进行别名是允许的。例：假设你有一个私人 PEAR 库，并希望使用 Composer 从 VCS 集成依赖。你的 PEAR 库包含以下资源包：BasePackage。IntermediatePackage 依赖于 BasePackage。TopLevelPackage1 和 TopLevelPackage2 都依赖于 IntermediatePackage。如果没有一个供应商别名，Composer 将使用 PEAR 渠道名称作为包名的一部分：pear-pear.foobar.repo/BasePackagepear-pear.foobar.repo/IntermediatePackagepear-pear.foobar.repo/TopLevelPackage1pear-pear.foobar.repo/TopLevelPackage2假设之后的某个时间，你希望将你的 PEAR 包迁移，使用 Composer 资源库和命名方案，并且采用 foobar 作为供应商名称。这样之前使用 PEAR 包的项目将不会看到更新的资源包，因为它们有不同的供应商名称（foobar/IntermediatePackage 与 pear-pear.foobar.repo/IntermediatePackage）。你可以通过从一开始就为 PEAR 资源库指定 vendor-alias 来避免这种情况的发生，以得到一个不会过时的包名。为了说明这一点，下面的例子会从你的 PEAR 资源库中得到 BasePackage、TopLevelPackage1 和 TopLevelPackage2 资源包，并从 Github 资源库中获取 IntermediatePackage 资源包：{ "repositories": [ { "type": "git", "url": "https://github.com/foobar/intermediate.git" }, { "type": "pear", "url": "http://pear.foobar.repo", "vendor-alias": "foobar" } ], "require": { "foobar/TopLevelPackage1": "*", "foobar/TopLevelPackage2": "*" }}Package如果你想使用一个项目，它无法通过上述任何一种