分享每一天-高效使用Composer的24个技巧

高效使用Composer的24个技巧

PHP 3244 0 创建时间：2020-11-04 17:43:44

composer

#### 高效使用Composer的24个技巧

#### 提示1：阅读文档
我真心的。从长远来看，该文档非常有用，花了几个小时阅读它可以为您节省更多时间。您会惊讶于Composer可以执行多少操作。

#### 提示2：请注意“项目”和“库”之间的区别
了解您是要创建“项目”还是“库”，这一点很重要。它们每个都需要一套单独的实践。

库是可重用的程序包，您可以将其添加为依赖项，例如symfony/symfony，doctrine/orm或elasticsearch/elasticsearch。

一个项目通常是一个应用程序，它依赖于几个库。它通常是不可重用的（没有其他项目将其作为依赖项）。典型示例是电子商务网站，客户支持系统等。

我将在下面的提示中区分库和项目。

#### 提示3：对应用程序使用特定的依赖项版本
如果要创建应用程序，则应使用最特定的版本来定义依赖关系。如果需要解析YAML文件，则应指定类似这样的依赖项"symfony/yaml": "4.0.2"。

即使该库遵循语义版本控制，在次要版本和修补程序版本中也可能存在向后兼容性中断。例如，如果您使用"symfony/symfony": "^3.1"，则3.2中可能已弃用某些内容，这可能会破坏应用程序测试。或者，PHP_CodeSniffer中可能修复了一个错误，它会检测代码中的新格式问题，这又可能导致构建损坏。

依赖项的更新应该是有意的，而不是偶然的。下面的提示之一将对其进行详细讨论。

听起来可能有些过激，但可以防止您的同事在向项目添加新库时意外更新所有依赖项（在代码审查期间可能会错过）。

#### 提示4：使用版本范围来存储库依赖项
如果要创建库，则应定义尽可能广泛的版本范围。如果创建使用symfony/yaml库进行YAML解析的库，则应按以下要求进行操作：

"symfony/yaml": "^3.0 || ^4.0"

这意味着您的库可以使用symfony/yaml任何Symfony 3.x或4.x版本。这很重要，因为此约束将传递给使用您的库的应用程序。

如果有两个库的需求冲突，例如一个需求~3.1.0和另一个需求~3.2.0，则安装将失败。

#### 提示5：您应composer.lock在应用程序中使用git

如果要创建项目，则肯定要提交composer.lockgit。这样可以确保每个人（您，您的同事，CI服务器和生产服务器）都以相同的依赖项版本运行该应用程序。

乍一看，这听起来可能是多余的-如技巧3中所述，您已经在约束中使用了特定版本。但是，不，您的依赖项还存在一些不受这些约束约束的symfony/console依赖项（例如取决于symfony/polyfill-mbstring）。因此，如果不提交composer.lock，您将不会获得完全相同的依赖关系集。

#### 提示＃6：将composer.lock进入.gitignore图书馆

如果您要创建一个库（我们称之为acme/my-library），则不应提交composer.lock文件。它对使用您的库的项目没有任何影响。

想象一下，acme/my-library使用monolog/monolog作为依赖项。如果您提交了composer.lock，则正在开发的每个人都acme/my-library将使用旧版本的Monolog。但是，当库完成后，您在实际项目中使用它时，可能会安装较新版本的Monolog，并且它可能与库不兼容。但是您以前没有注意到它，因为composer.lock！

最好放进composer.lock您的.gitignore书中，以免造成意外。

如果要确保该库与其依赖关系的不同版本兼容，请阅读下一个技巧！

#### 提示＃7：使用不同版本的依赖项运行Travis CI构建

本技巧仅适用于库（因为您为应用程序使用特定版本）。

如果要构建开源库，则可能正在使用Travis CI来运行其构建。

默认情况下，Composer安装的约束所允许的最新版本的依赖关系composer.json。这意味着对于依赖关系约束^3.0 || ^4.0，构建将始终使用最新版本的v4版本。由于3.0从未经过测试，因此该库可能与它不兼容，这会使您的用户感到难过。

幸运的是，Composer提供了一个安装最低可能版本的依赖项的开关--prefer-lowest（应该与之配合使用，--prefer-stable以防止安装不稳定版本）。

更新后的.travis.yml配置可能如下所示：

```php
language: php

php:
  - 7.1
  - 7.2

env:
  matrix:
    - PREFER_LOWEST="--prefer-lowest --prefer-stable"
    - PREFER_LOWEST=""

before_script:
  - composer update $PREFER_LOWEST

script:
  - composer ci
```
在我的mhujer / fio-api-php库和Travis CI上的构建矩阵中实时查看

即使此解决方案可以解决大多数不兼容问题，但请记住，最低和最新版本之间有很多依赖关系组合。而且它们可能不兼容。

#### 提示＃8：按名称对require和require-dev中的软件包进行排序

最好将软件包放在其中require并按require-dev名称排序。在重新分支分支时，它可以防止不必要的合并冲突。因为如果您在两个分支的列表末尾添加了一个程序包，则每次都会发生合并冲突。

手动完成是一项繁琐的任务，因此最好在以下位置进行配置composer.json：
```php

{
...
    "config": {
        "sort-packages": true
    },
…
}
```

下次，您require将新包装添加到适当的位置（而不是添加到末尾）。

#### 提示＃9：composer.lock在进行基础调整或合并时，请勿尝试合并

如果您向composer.json（和composer.lock）添加新的依赖关系，并且在合并分支之前，master中又添加了另一个依赖关系，则需要重新设置分支基础。并且您将在中发生合并冲突composer.lock。

您永远不要尝试手动解决此冲突，因为该composer.lock文件包含在中定义的依赖项的哈希composer.json。因此，即使您解决了冲突，生成的锁定文件也不正确。

最好的办法是.gitattributes在项目根目录中创建以下行，这意味着git甚至不会尝试合并composer.lock：

/composer.lock -merge

您可以通过使用基于中继的开发中建议的短暂功能分支来解决此问题（无论如何，您都应该这样做）。当您有一个短暂的分支（该分支会迅速合并）时，合并冲突的风险将降至composer.lock最低。您甚至可以创建一个分支，仅用于添加依赖项并立即将其合并。

但是，如果在重新定基composer.lock时遇到合并冲突，该怎么办？使用master的版本来解决它，因此仅在composer.json（新添加的软件包）中会有更改。然后运行composer update --lock，它将composer.lock使用更改更改文件composer.json。现在，您可以分阶段进行更新 composer.lock并继续进行变基。

#### 提示＃10：了解之间的差别require和require-dev

重要的是要注意require和require-dev块之间的区别。

运行应用程序或库所需的程序包应在require（例如Symfony，Doctrine，Twig，Guzzle等）中定义。如果要创建库，请注意放置的内容require。因为本节中的每个依赖项也是使用库的应用程序的依赖项。

开发应用程序（或库）所需的程序包应在require-dev（例如PHPUnit，PHP_CodeSniffer，PHPStan）中定义。

#### 提示＃11：安全更新依赖项

我猜我们可以就应该定期更新依赖项达成一致。我要在这里讨论的是，依赖项更新应该是明确而有意的，而不是仅通过其他一些工作来完成。如果您重构某些内容并同时更新某些库，则无法轻易判断出该应用是否因重构或更新而损坏。

您可以使用composer outdated命令查看可以更新哪些依赖项。最好包含--direct（或-D）开关以仅列出中指定的依赖项composer.json。还有一个-m开关仅列出次要版本更新。

对于每个过时的依赖项，请执行以下步骤：

创建一个新分支
将依赖版本更新composer.json为最新版本
运行composer update phpunit/phpunit --with-dependencies（用phpunit/phpunit您要更新的库替换）
在Github上的库存储库中检查CHANGELOG以查看是否有任何重大更改。如果是这样，请更新应用程序
在本地测试应用程序（如果您使用的是Symfony，则可以在调试栏中找到弃用警告）
提交更改（composer.json，composer.lock以及其他所有新版本正常工作所需的内容）
等待配置项构建完成
合并和部署
有时，一次更新更多的依赖关系是有意义的，例如，在更新Doctrine或Symfony时。在这种情况下，您可以在update命令中将它们全部列出：

```php
composer update symfony/symfony symfony/monolog-bundle --with-dependencies

```
或者，您可以使用通配符来更新特定命名空间中的所有依赖项：

```php
composer update symfony/* --with-dependencies
```

我知道这听起来很乏味，但是您可能偶尔会更新依赖项，因此值得额外的安全性。

可以接受的一种快捷方式是require-dev一次更新所有依赖项（如果它们不需要更改代码，否则我建议使用单独的分支以简化代码检查）。

#### 提示＃12：您可以在中定义其他类型的依赖项composer.json

除了将库定义为依赖项之外，您还可以在那里定义其他内容。

您可以定义您的应用程序/库支持哪些PHP版本：

```php
"require": {
    "php": "7.1.* || 7.2.*",
}
```
您还可以定义应用程序/库所需的扩展名。当您尝试对应用程序进行docker化或新同事首次设置该应用程序时，它非常有用。

```php
"require": {
    "ext-mbstring": "*",
    "ext-pdo_mysql": "*",
}
```
,（您应该使用*扩展版本，因为它们可能有点不一致）。

提示＃13：composer.json在CI生成期间验证
composer.json并且composer.lock应始终保持同步。因此，最好对其进行自动检查。只需将其作为构建脚本的一部分添加，它将确保composer.lock与composer.json以下内容同步：

composer validate --no-check-all --strict

#### 提示＃14：在PHPStorm中使用Composer插件
有一个用于PHPStorm的composer.json插件。composer.json手动更改时，它会添加自动完成功能和一些验证。

如果使用其他IDE（或仅使用代码编辑器），则可以针对其JSON模式设置验证。

#### 提示15：在中指定生产PHP版本composer.json

如果您和我一样，并且有时在本地运行预发布的PHP版本，则有可能将依赖项更新为无法在生产环境中使用的版本。现在，我正在使用PHP 7.2.0，这意味着我可以安装在7.1上不起作用的库。当生产运行7.1时，安装将在那里失败。

但无需担心，这是一个简单的出路。只需在以下config部分中指定生产PHP版本composer.json：

```php
"config": {
    "platform": {
        "php": "7.1"
    }
}
```
不要将它与requiresection混淆，section的行为有所不同。您的应用程序可以在7.1或7.2上运行，并同时将7.1指定为平台（这意味着依赖项将始终更新为与7.1兼容的版本）：

```php
"require": {
    "php": "7.1.* || 7.2.*"
},
"config": {
    "platform": {
        "php": "7.1"
    }
},
```

#### 提示16：使用自托管Gitlab的私有软件包
建议将其vcs用作存储库类型，并且Composer应该确定获取软件包的正确方法。例如，如果您要从Github添加一个fork，它将使用其API下载.zip文件，而不是克隆整个存储库。

但是，对于私人的Gitlab安装，情况则更为复杂。如果您将其vcs用作存储库类型，则Composer会检测到它是Gitlab安装，将尝试使用API下载该软件包（这需要API密钥。我不想对其进行设置，因此我决定进行此设置（使用SSH进行克隆）：

首先使用以下类型指定存储库git：

```php
"repositories": [
    {
        "type": "git",
        "url": "git@gitlab.mycompany.cz:package-namespace/package-name.git"
    }
]
```
然后像往常一样使用该软件包：

```php
"require": {
    "package-namespace/package-name": "1.0.0"
}
```
#### 提示＃17：如何从fork中临时使用带有错误修正的分支

如果您在某个公共库中找到一个错误，并在Github的fork中修复了该错误，则需要从该存储库而不是正式库中安装该库（直到该错误修正被合并并发布了固定版本）。

可以使用内联别名轻松完成：

```php
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}
```
您可以通过推动它前本地测试修正错误的使用path作为存储库类型。

#### 提示＃18：安装prestissimo可以加快软件包的安装速度

有一个Composer插件hirak / prestissimo，可通过并行下载依赖项来加快依赖项的安装。

最好的是什么？您只需全局安装一次，它将自动对所有项目运行：

```php
composer global require hirak/prestissimo
```

#### 提示＃19：如果不确定，请测试版本约束
即使阅读了文档，编写正确的版本约束有时也可能很棘手。

幸运的是，有一个Packagist Semver Checker，您可以在其中检查哪些版本符合指定的约束。它不仅可以分析版本约束，还可以从Packagist下载数据以显示实际发布的版本。

请参阅的结果symfony/symfony:^3.1。

#### 提示＃20：在生产中使用权威的类映射

您应该在生产中生成权威的类映射。通过将所有内容包括在类映射中并跳过任何文件系统检查，它将加速类加载。

您可以通过将其作为生产版本的一部分来运行来实现：

```php
composer dump-autoload --classmap-authoritative
```

#### 提示＃21：配置autoload-dev测试

您不想在生产类映射中包括测试文件（由于文件大小和内存）。可以通过配置autoload-dev（类似于autoload）来完成：
```php

"autoload": {
    "psr-4": {
        "Acme\\": "src/"
    }
},
"autoload-dev": {
    "psr-4": {
        "Acme\\": "tests/"
    }
},
```
#### 提示＃22：尝试Composer脚本

Composer脚本是用于创建构建脚本的轻量级工具。我已经写了一篇关于它们的单独文章。

提示＃23：使用Composer CLI删除软件包
添加于四月23th 2019

删除软件包的最佳方法composer.json是使用Composer命令行界面。在以下示例中，我将删除，phpoffice/phpspreadsheet因为项目中不再需要它。您会看到不再需要的子依赖关系也会自动卸载：
```php

composer remove phpoffice/phpspreadsheet

Package operations: 0 installs, 0 updates, 3 removals
  - Removing phpoffice/phpspreadsheet (1.6.0)
  - Removing markbaker/matrix (1.1.4)
  - Removing markbaker/complex (1.4.7) 
```

composer.json与从运行中手动删除它相比，这是一种更好的方法composer update。这将对已安装的依赖项进行不相关的更改（有关如何安全更新依赖项的更多信息，请参见提示11）。

#### 提示＃24：不要使用传递依赖中的代码
 
假设您需要一些库（例如AcmePayment），而该库又需要nette/utils包（在这种情况下nette/utils称为传递依赖-它是依赖的依赖）。

由于nette/utilspackage提供了许多帮助程序功能，因此您开始使用它们。但是随后您停止使用AcmePayment库，并将其从项目中删除。在意外的情况下，nette/utils也将其删除，因为在项目中不需要（从Composer的角度来看）。

解决的办法是包括您在使用所有库require的部分composer.json。有一个名为ComposerRequireChecker的工具，该工具应该能够检测到丢失的工具。

#### 翻译文档地址：
https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/

高效使用Composer的24个技巧

商品推荐

广告推荐

推荐文章