README

补丁集应用的Composer插件

‼️ 新功能 支持 composer 分支 v1.x 和 v2.x。

此插件可以自动将补丁应用到您项目中的任何依赖项。

其中一个最显著的特点是它可以应用特殊类型的 patchset 的 composer 包中的补丁。这非常方便，因为您可以将所有补丁存储在一个存储库中，并以非常可预测的方式自动应用到所有系统，包括开发人员的机器。您还可以轻松通过packagist将补丁集分发给整个社区。

它是一种（某种程度上）替代其他两个优秀插件的方法

继续阅读此文档以获取更深入的解释，或直接跳转到

功能比较表

¹ 根包打补丁是例外，请参阅使用文档中的应用根包补丁。

功能描述

从专门的composer包中应用补丁（打包您的补丁集！）。
每个补丁都可以有版本约束（composer semver），与目标包进行校验。

这意味着您可以在无法应用补丁的情况下失败构建，同时在同一个补丁集中存储多个包版本的补丁。
使用 patch 命令应用补丁，并在不可用的情况下回退到 git apply。
不无谓地重新安装包。
重新安装（清理）已打补丁但补丁已删除的包，确保在多次更新后状态一致。
即使特定包（版本）的补丁顺序发生变化，也会重新打补丁。
在包级别上删除重复的补丁。
不过度绑定到composer内部。所有打补丁将在主要更新/安装过程之后一次性执行，使其更简单、更容易分析。

这也意味着您在过程开始之前就有保证插件/补丁是最新版本。否则，在第一次composer安装（例如，完全没有vendor目录）以及随后的安装中，让插件保持一致的行为非常困难（如果不是不可能的话）。

双倍composer更新/安装对于构建是不必要的。

使用Git应用补丁

默认情况下，库将尝试使用 patch 命令，如果不可用，则回退到 git。您可以为每个补丁强制使用git（请参阅：使用文档）。

在其他插件中报告了使用 git apply 时的一些问题，这些插件针对的是未作为源安装的包（没有git存储库；.git目录）。我无法在git 2.X中重现此问题，但是为此潜在问题已实施了一个解决方案。

- If the target package has `.git` directory, then the patches are applied relative to target package root
- If no git repo in target package then patches are applied from root project directory

鸡生蛋问题

通过composer插件进行修补有一个大问题 - 您无法在首次安装时捕捉到所有事件。此外，在包安装/删除时应用补丁很容易出错，因为您永远无法预测与其他插件之间的冲突。因此，在所有内容安装完成之前收集和应用补丁，可能会导致最终状态无效。此插件采用不同的方法 - 它在安装/更新完成后立即执行所有操作，就在自动加载导出之前（以防修补会改变它）。

这保证了一致性状态，因为插件会将当前状态与所需状态进行比较，并仅执行必要的操作以到达那里。

这有一个缺点，如果您的项目使用任何将文件从供应商复制到项目根目录的composer插件，那么您应该修补根包，因为补丁应用将在那些插件完成工作之后发生，所以在供应商中修补源文件将没有任何效果。

为什么不使用远程补丁

此插件不会直接从外部源（http）下载补丁。我认为这是一种不良做法，永远不会支持它。我甚至不会评论使用未加密连接下载补丁而不进行SHA检查的情况。那么，如果有人在两年后想要使用您的软件，而补丁已经不再可用怎么办呢？

此外，您无法在任何composer包中指定补丁。您必须使用专用包来为此目的。我很难想象一个合法的场景，在这种情况下，安装包X会自动修补项目中的一些其他包Y，而无需明确宣传为补丁集。

creativestyle / composer-plugin-patchset

维护者

详细信息