使用PHP 7.4编码并通过Rector和GitHub操作部署到7.1

PHP开发人员希望能够访问该语言的最新功能，但由于各种原因，他们可能无法访问。可能是客户端的服务器运行在较旧的版本上，无法升级，或者CMS必须支持遗留代码，否则用户群会显著缩减，等等。

但有一个解决方案：我们可以使用代码转换程序将使用新语法的代码转换为旧语法。Transpilers两全其美；开发人员可以使用最新的特性编写代码，并为生产生成可与该语言以前版本一起工作的资产。

在我的上一篇文章中，我介绍了Rector，这是一个PHP重构工具。现在让我们把它付诸实践。在本文中，我们将探索如何使用PHP 7.4代码开发WordPress插件，并通过Rector和GitHub操作发布包含PHP 7.1及更低版本代码的WordPress插件。

我开始转载我的WordPress插件，因为WordPress决定不提高PHP的最低版本，目前是5.6。然后你可能会想，为什么我要转换到PHP 7.1而不是PHP 5.6呢？

这有两个原因。首先，Rector根据规则执行转换，例如ArrowFunctionToAnonymousFunctionRector，它将代码从PHP 7.4的箭头函数降级为PHP 7.3及更低版本的匿名函数：

Class SomeClass{PUBLIC Function RUN(){$delimiter="；，"；；-$Callable=FN($Matches)=>；$delimiter。Strtolower($Matches[1])；+$Callable=函数($Matches)使用($分隔符){+返回$分隔符。Strtolower($Matches[1])；+}；}}。

到目前为止实施的大约20条降级规则中，只有少数几条是从PHP 7.1到7.0，没有一条是从7.0到5.6。因此，达到7.0的支持有限，目前还没有支持5.6的目标。

这并不意味着Rector不能支持PHP 5.6，但这项工作必须完成。如果这些规则最终得以实施(在WordPress将其最低版本提升到7.1之前，否则就不再需要它们了)，那么我就可以瞄准一个更低的PHP版本了。

第二个原因与第三方PHP依赖有关。这些代码也必须与我们的应用程序代码一起传输，这样做可能需要付出很大的努力。

例如，如果一个依赖项需要PHP 7.1，而我将PHP 7.1作为我的应用程序的目标，那么该依赖项就会被直接支持，我不需要转换它的代码。但是如果我的目标是PHP 7.0或5.6，那么我确实需要转换它。

传输第三方依赖项可能会变得具有挑战性，因为它们不在我的控制之下。仅仅浏览它的代码是不够的；我需要做彻底的研究，以确保依赖项中的所有PHP 7.1代码都可以被转译。我没有注意到的一个功能很可能会使应用程序在运行时失败。

在我的例子中，我的应用程序有一个依赖项需要PHP 7.2，几十个依赖项需要PHP 7.1(稍后将详细介绍)。因为我没有无限的资源，所以我选择以PHP 7.1为目标并传递一个依赖项，而不是以7.0为目标并传递数十个依赖项。

因此，运行WordPress 5.6和7.0的用户将无法使用我的WordPress插件，但这是一个我很满意的取舍。

当声明应用程序现在可以使用PHP 7.4代码时，这并不一定意味着它可以使用PHP 7.4中引入的所有特性。相反，它只能使用那些存在Rector规则的功能来降级。

此外，并不是所有的功能都可以转换，有些功能也不会因为这样或那样的原因而转换。

例如，在PHP 7.4中引入的新常量中，常量SO_LABEL、SO_PEERLABEL和其他是特定于FreeBSD的套接字选项。这似乎太具体了，所以我不指望任何人为他们实施校长规则。

因此，这个应用程序将不会完全支持PHP 7.4(如果任何人确实需要常量SO_LABEL，它就不会存在)；相反，它可以完全支持PHP 7.1，并通过PHP 7.2、7.3和7.4中的一组特性进行增强。

下面的列表列出了当前支持的用于发布PHP 7.1应用程序的功能。该列表(随着社区实施剩余的降级规则，势必会扩大)还包括Symfony PolyFill包支持的功能：