语序有误，错别字
Mr-houzi
5年前
修改理由：
此投稿已在 5年前 合并。
内容修改：
| Old | New | Differences |
|---|---|---|
| 1 | ||
| 2 | 1 | 在创建 PHP 的应用程序或库时，通常有三种依赖关系： |
| 3 | 2 | |
| 4 | 3 | * 硬依赖性：你的应用程序/库需要此依赖才能够正常运行 |
| 5 | 4 | * 可选的依赖关系：例如一个 PHP 库可以为不同的框架提供一个功能 |
| 6 | * 开发依赖：调试工具，测试框架等... | |
| 5 | * 开发依赖：调试工具，测试框架等... | |
| 7 | 6 | ## 如何管理这些依赖关系? |
| 8 | 7 | |
| 9 | 8 | <div class="text-center"><img src="https://cdn.learnku.com/uploads/images/201801/10/1/oIypZMwgdG.png" width="300" /></div> | … | … |
| 41 | 40 | 截止到目前还是很顺利。那么什么地方会出错呢? 主要在 `require-dev` 上会有一定的限制。 |
| 42 | 41 | |
| 43 | 42 | |
| 44 | ||
| 43 | ||
| 45 | 44 | ## 问题和限制 |
| 46 | 45 | |
| 47 | 46 | ### 过多的依赖关系 | … | … |
| 53 | 52 | **觉得段落长，直接看这里：** 对你引入的依赖进行负责，并且争取少依赖。 |
| 54 | 53 | |
| 55 | 54 | |
| 56 | ||
| 55 | ||
| 57 | 56 | |
| 58 | 57 | ### 强关系冲突 |
| 59 | 58 | … | … |
| 85 | 84 | 在某些情况下可能会工作但是很可能大部分的情况下都会失败. 这种场景可能有点傻因为你不 _太_ 可能在同一时间同时包含这两个包并且你更不可能想要去支持这个场景. |
| 86 | 85 | |
| 87 | 86 | |
| 88 | ||
| 87 | ||
| 89 | 88 | ### 无法测试的依赖关系 |
| 90 | 89 | |
| 91 | 90 | 请看示例 `composer.json`: | … | … |
| 119 | 118 | 至少现在你是无法知道的。 |
| 120 | 119 | |
| 121 | 120 | |
| 122 | ||
| 121 | ||
| 123 | 122 | |
| 124 | 123 | ## 解决方案 |
| 125 | 124 | … | … |
| 168 | 167 | |
| 169 | 168 | 使用PHAR时还有一些其他的事情需要记住： |
| 170 | 169 | |
| 171 | * 它们很难跟踪，因为在Composer 中 | |
| 170 | * 它们很难跟踪，因为在Composer 中对于它们没有原生的支持。然而，存在一些解决方案例如这个Composer 插件[tooly-composer-script](https://github.com/tommy-muehle/tooly-composer-script) 或者[PhiVe](https://phar.io/) 一个PHAR 安装程序 | |
| 172 | 171 | * 如何管理版本取决于项目。 一些项目提供了一个具有不同稳定通道的“自我更新”命令，一些项目提供了独特的下载端点和最新版本，一些项目使用了GitHub发行版，并为每个版本发布了一个PHAR。 |
| 173 | 172 | |
| 174 | 173 | |
| 175 | ||
| 174 | ||
| 176 | 175 | ### 使用多个存储库 |
| 177 | 176 | |
| 178 | 177 | 迄今为止最流行的技术之一。因此，我们不需要在一个 `composer.json` 中要求所有的桥依赖关系，而是将这个包分解到多个存储库中。 | … | … |
| 183 | 182 | |
| 184 | 183 | 这种方法的主要优点是，它仍然相对简单，不需要任何额外的工具，除了最终存储库分配器像 [splitsh](https://github.com/splitsh/lite)，例如 Symfony，Laravel 和 PhpBB。缺点是你现在有多个包来维护，而不是一个。 |
| 185 | 184 | |
| 186 | ||
| 185 | ||
| 187 | 186 | |
| 188 | 187 | ### 调整配置 |
| 189 | 188 | … | … |
| 212 | 211 | 在我的经验中，它是有效的，但这导致了臃肿的测试脚本，在运行中它们相对缓慢，难以维护，对新的贡献者也不太友好. |
| 213 | 212 | |
| 214 | 213 | |
| 215 | ||
| 214 | ||
| 216 | 215 | |
| 217 | 216 | ### 使用多个composer.json |
| 218 | 217 | … | … |
| 306 | 305 | 所以现在我们可以调用 `vendor-bin / phpstan / vendor / bin / phpstan` 和 `vendor-bin / phpmetrics / vendor / bin / phpstan` 来轻松地使用PhpStan和PhpMetrics。 |
| 307 | 306 | |
| 308 | 307 | |
| 309 | ||
| 308 | ||
| 310 | 309 | 现在我们更进一步的以一个库在不同框架的引用为例 |
| 311 | 310 | |
| 312 | 311 | ```php | … | … |
| 375 | 374 | 为了测试核心库之间的引用关系，你需要创建3个不同的单元测试文件，其中每一个都有 `autoload.php`（例如： Symfony 的引用文件 `vendor-bin/symfony/vendor/autoload.php`）。 |
| 376 | 375 | |
| 377 | 376 | |
| 378 | ||
| 377 | ||
| 379 | 378 | 如果你真的试试，你将会发现这种方法的一个主要缺点： 冗余配置。 确定你需要重复的根配置文件 `composer.json` 到其他两个 `vendor-bin/{symfony,laravel}/composer.json`, 调整自动加载变化的文件路径，当你需要一个新的依赖，你需要在其他的`composer.json`包含它。这是不可控的，所以 [composer-inheritance-plugin](https://github.com/theofidry/composer-inheritance-plugin)出现了。 |
| 380 | 379 | |
| 381 | 380 | 这个小包装插件[composer-merge-plugin](https://github.com/wikimedia/composer-merge-plugin)将`vendor-bin/symfony/composer.json`内容合并到根`composer.json`。所以不是如下： | … | … |
| 406 | 405 | 其他的配置，自动加载和依赖将被包含在根 `composer.json` 。没有配置的， [composer-inheritance-plugin](https://github.com/theofidry/composer-inheritance-plugin)是一个瘦小的包[composer-merge-plugin](https://github.com/wikimedia/composer-merge-plugin)来预配置任何使用[composer-bin-plugin](https://github.com/bamarni/composer-bin-plugin)。 |
| 407 | 406 | |
| 408 | 407 | |
| 409 | ||
| 408 | ||
| 410 | 409 | 您可以检查安装它需要的依赖，通过： |
| 411 | 410 | |
| 412 | 411 | $ composer bin symfony show |
| 413 | 412 | |
| 414 | 413 | 我在很多项目中使用这个方法,像[alice](https://github.com/nelmio/alice)，不同于PhpStan和PHP-CS-Fixer这样的静态分析工具和框架桥接器。另一个例子是[alice-data-fixtures](https://github.com/theofidry/alicedatafixtures),其中有很多不同的ORM桥持久层（Doctrine ORM, Doctrine ODM, Eloquent ORM，等）和框架的整合。 |
| 415 | 414 | |
| 416 | 作为替代phars的另外一种工具，我在多个私人项目中使用了它，并且它工作得很好。 | |
| 415 | 作为替代phars的另外一种工具，我在多个私人项目中使用了它，并且它工作得很好。 | |
| 417 | 416 | ## 结论 |
| 418 | 417 | |
| 419 | 418 | 我相信有些人会发现一些奇怪的方法或不推荐使用它们。 这里的目标不是判断或者推荐一个特殊的东西，而是列出一些可能的方法来管理一些依赖关系，以及每个依赖关系的优点和缺点。 所以，根据你的问题和你的个人喜好，选择一个最适合你的。 正如人们所说，没有解决办法，只有权衡。 |
关于 LearnKu
粤公网安备 44030502004330号