思考

当你有一个好的idea，写了一个自我感觉还不错的工具或者组件，并迫不及待的想让别人去试试的时候，你会怎么做？

把代码贴在博客	需要花时间复制粘贴，阅读代码
把代码发布在github	还是需要花时间down\clone，不能直接组件化加载
把代码发布在composer ✔️	只需要知道是干嘛的，组件化引入直接使用

或者你看到一个好的composer的类库，为什么可以直接加载进来，它是怎样被发布出来供大家使用的呢？

介绍

Composer 是一个用于 PHP 依赖管理的工具。它实现了让你声明项目所依赖的库，并帮你完成安装 / 更新过程。

composer.json

最熟悉的文件，可以手写也可以命令行生成，其中定义了我们当前项目的依赖项。json里有很多配置项，下面我们用一个熟悉的包guzzlehttp来举例说一下每个字段代表的意义。

{
     "name": "guzzlehttp/guzzle",//composer 包名
     "type": "library",//这是默认类型，它会简单的将文件复制到vendor目录
     "description": "Guzzle is a PHP HTTP client library",//一个包的简短描述。通常这个最长只有一行。
     "keywords": ["framework", "http", "rest", "web service", "curl", "client", "HTTP client"],//在composer搜索用到
     "homepage": "http://guzzlephp.org/",//项目主页
     "license": "MIT",//包的许可协议
     "authors": [//作者
         {
             "name": "Michael Dowling",
             "email": "mtdowling@gmail.com",
             "homepage": "https://github.com/mtdowling"
         }
     ],
     "require": {//必要的依赖
         "php": ">=5.5",
         "guzzlehttp/psr7": "^1.4",
         "guzzlehttp/promises": "^1.0"
     },
     "require-dev": {//开发版的依赖，一般帮助开发阶段使用
             "ext-curl": "*",//可以帮你指定需要的 PHP 扩展（包括核心扩展）例如在编辑器的自动提示功能
             "phpunit/phpunit": "^4.8.35 || ^5.7 || ^6.4 || ^7.0",
             "psr/log": "^1.0"
     },
     "autoload": {//自动加载映射
             "files": ["src/functions_include.php"],//自动加载的函数库文件 相当于直接require该文件，直接使用其中function 数组可配置多个
             "psr-4": {
                "GuzzleHttp\\": "src/"
             }
     },
     "autoload-dev": {//一般将单元测试的路径放在这里
             "psr-4": {
                "GuzzleHttp\\Tests\\": "tests/"
             }
     },
     "suggest": {//建议安装的包
             "psr/log": "Required for using the Log middleware"
     },
     "extra": {//可选项
             "branch-alias": {
                "dev-master": "6.3-dev"
             }
     },
     "bin": [//composer安装时会将script脚本文件复制到vendor/bin中 比如 php vendor/bin/script 执行一些组件的脚本功能
         "bin/script"
     ]
}

Coding

下面我写了一个最简单的工具类，目录如下

├── README.md
├── composer.json
└── src
    ├── Db.php
    ├── DbInterface.php
    ├── Test.php
    └── function.php

代码都在src目录下，composer.json内容如下

{
    "name": "ty_coder/composertest",
    "description": "a test composer library ",
    "authors": [
        {
        "name": "tyCoder"
        }
    ],
    "license": "MIT",
    "require": {
        "php": ">=5.4"
    },
    "autoload": {
        "psr-4": {
            "ty\\": "src/"
        },
        "files": [
            "src/function.php"
        ]
    }
}

然后发布在github上，下一步我们将项目发布在composer。

发布

登陆composer仓库，访问https://packagist.org/packages/submit

composer仓库会帮我们验证项目是否满足发布条件，在我们完成发布后，就可以通过composer require 在任何项目中加载我们编写的工具类库了。不过还有一个问题，我们想要更新我们的工具类库，并保留之前的版本，我们该怎样做？这些composer其实都为我们准备了超级方便的钩子设置方案了，请看下图。

通过个人资料我们拿到自己的API token，然后去我们的github的仓库页，在设置里找到Webhooks选项，设置一下钩子即可，我们每次git事件都会同步给composer，每次的tag会在composer发布一个版本，注意composer会忽略前缀，所以v这个字母被忽略了奥。

image

require

执行composer require ty_coder/composertest 后，我们的工具类库被加载到vendor目录下，让我们简单测试一下。

image

好的，我们发现编辑器已经提示我们，我们的类库文件被找到啦，那么本文在这里对composer的一些常用知识的简单介绍也告一段落了。

other

在阅读源码的过程中我们会发现，优良的composer类库或者项目中还会有单元测试模块tests目录，二进制脚本目录bin目录，自动化部署文件.travis.yml文件，还有Dokerfile等等。所以composer中是可以有其他类型文件存在的，特定的文件还会触发特定的功能事件，详细的我们可以去官方文档进一步学习奥。