2.3. 创建扩展包

2018

2018

扩展包

本章将告诉你如何通过 Composer 安装扩展包

每个项目都是一个扩展包

一旦你的目录有一个 composer.json 文件，这个目录就是一个包。当你给一个项目添加一个 require 依赖时，此时你正在创建一个依赖于其他包的包。项目和扩展包唯一不同之处在于，项目是一个没有名称的包。

为了使该包可安装，你需要指定一个名称，通过在 composer.json 中添加 name 属性：

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

在上例中，项目名是 acme/hello-world，其中 acme 是当前项目出处名称，如果它被设计为可以被其他人安装，该名称是必须的。

注意：如果你不知道该使用什么作为提供者名称，你的 GitHub 用户名是个不错的选择。虽然包的名称不区分大小写，但通常采用全部小写，使用破折号分离单词。

库(包)版本

在绝大数情况下，你将使用某种版本控制系统（如 git、svn、hg 或 fossil）来维护你的库(包)。在这些情况下，Composer 会从你的 VCS 中推断出版本，并且你不应该在 composer.json 中把版本写死。（请看 Versions 文章）了解 Composer 如何使用 VCS 分支和标记来解决版本约束。

如果你手动维护（即没有 VCS），你需要通过在 composer.json 文件中添加一个 version 值来明确指定版本：

{
    "version": "1.0.0"
}

注意：当你通过硬编码添加 VCS 版本时，版本可能会与标记名冲突。Composer 将无法确定版本号。

VCS 版本

Composer 使用的 VCS 分支和标记分支解决你在 require 字段中指定的版本约束。当有可用版本时，Composer 会查看所有标记和分支，并将其名称转换为内部可选列表，然后根据你提供的版本约束进行匹配。

有关 Composer 如何处理标记和分支以及如何处理包版本约束的更多信息，请阅读版本文章。

Lock 文件

如果你想要的话你可以向你的仓库提交 composer.lock 文件。这确保了你的团队总是在相同版本的依赖下测试。然而，这个 Lock 文件不会对其他依赖它的项目有影响。他只会影响主项目。

如果你不想提交 Lock 文件并且你在使用 Git，那就把它添加到 .gitignore 文件中。

发布到版本控制系统

一旦你有一个包含 composer.json 文件的版本仓库（例如 Git）,你的库就总是可以被 Composer 安装的。在这个例子里我们会把 acme/hello-world 库发布到 Github 的 github.com/username/hello-world 中。

现在，为了测试 acme/hello-world 包，我们本地创建了一个项目。我们叫它 acme/blog。这个 blog 项目会依赖 acme/hello-world。我们可以在某处创建一个包含 composer.json 文件的 blog 目录来完成它：

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

因为我们不会把 blog 作为一个库去发布，所以 name 字段不是必须的。

现在我们需要告诉 blog 应用去哪找 hello-world 依赖。我们通过向 composer.json 文件添加 repositories 项来完成此工作：

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

要了解具体 repositories 是怎样起作用以及其他可用的类型，查看 Repositories.

这就是全部，你现在可以通过执行 Composer 的 install 命令来安装依赖了！

回顾：任何包含 composer.json 的 git/svn/fossil 仓库都能通过指定 repositories 和通过 require 字段声明依赖来添加到你的项目中。