库

本章将告诉你如何让你的库可以通过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会从你的版本控制系统中推断版本，因此你不应该在composer.json文件中指定版本。（请参阅版本文章，了解Composer如何使用版本控制系统的分支和标签来解析版本约束。）

如果你是手动维护包（即不使用版本控制系统），则需要在你的composer.json文件中添加一个version值来明确指定版本。

{
    "version": "1.0.0"
}

注意： 当您向版本控制系统（VCS）添加硬编码版本时，该版本会与标签名称冲突。Composer 将无法确定版本号。

VCS版本控制

Composer 会利用你的版本控制系统（VCS）的分支和标签功能，将你在 require 字段中指定的版本约束解析为特定的文件集。在确定有效的可用版本时，Composer 会查看你所有的标签和分支，并将它们的名称转换为内部选项列表，然后将其与你提供的版本约束进行匹配。

想了解Composer如何处理标签和分支，以及如何解析包版本约束，请阅读版本一文。

锁定文件

对于你的库，如果你愿意，可以提交 composer.lock 文件。这能帮助你的团队始终针对相同的依赖版本进行测试。不过，这个锁文件对依赖它的其他项目不会有任何影响，它只对主项目有效。

如果你不想提交锁定文件，并且你正在使用git，请将其添加到.gitignore中。

发布到版本控制系统

一旦你有一个包含composer.json文件的版本控制系统（VCS）仓库（例如git），你的库就已经可以通过composer安装了。在这个例子中，我们将在GitHub上的github.com/username/hello-world发布acme/hello-world库。

现在，为了测试安装acme/hello-world包，我们在本地创建一个新项目。我们将其命名为acme/blog。这个博客将依赖于acme/hello-world，而后者又依赖于monolog/monolog。我们可以通过在某个位置创建一个新的blog目录来实现这一点，该目录包含一个composer.json文件：

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

在这种情况下，名称是不需要的，因为我们不想将该博客作为库发布。这里添加名称是为了明确所描述的是哪个composer.json。

现在我们需要告诉博客应用在哪里可以找到hello-world依赖项。我们通过向博客的composer.json添加包仓库规范来实现这一点：

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

有关包仓库的工作原理以及其他可用类型的更多详细信息，请参阅仓库。

就是这样。现在你可以通过运行Composer的install命令来安装依赖项了！

**回顾：**任何包含composer.json的git/svn/hg/fossil代码库都可以通过指定包代码库并在require字段中声明依赖项来添加到你的项目中。

发布到Packagist

好了，现在你可以发布包了。但是每次都指定版本控制系统仓库很麻烦。你不会想强迫所有用户都这么做的。

你可能已经注意到的另一件事是，我们没有为monolog/monolog指定包仓库。这是怎么做到的呢？答案是Packagist。

Packagist 是 Composer 的主要包仓库，并且默认启用。任何发布在 Packagist 上的内容都可以通过 Composer 自动获取。由于Monolog 在 Packagist 上，我们可以依赖它，而无需指定任何额外的仓库。

如果我们想与全世界分享hello-world，我们也会将其发布到Packagist上。

你访问Packagist并点击“提交”按钮。如果尚未注册，系统会提示你进行注册，之后你就可以提交你的版本控制系统（VCS）仓库的URL，此时Packagist将开始爬取该仓库。完成后，你的包就会对所有人开放！

轻量级分发包

像.github目录这类无用信息，或者大型示例、测试数据等，通常不应包含在分布式软件包中。

.gitattributes 文件是一个特定于 git 的文件，类似于 .gitignore，也位于库的根目录下。如果该文件存在且被 git 跟踪，它会覆盖本地和全局配置（分别是 .git/config 和 ~/.gitconfig）。

使用.gitattributes来防止不必要的文件使压缩分发包变得臃肿。

.gitattributes

/demo export-ignore
phpunit.xml.dist export-ignore
/.github/ export-ignore

通过检查手动生成的zip文件来测试它：

git archive branchName --format zip -o file.zip

**注意：**文件仍会被git跟踪，只是不会包含在zip分发版本中。这仅适用于从GitHub、GitLab或Bitbucket获取的、通过dist安装的包（即标记的发布版本）。