自从已故的 Alex Mills 在 WordPress Trac 上开了一张名为 Plugin Dependencies 的工单（又一张 Plugin Dependency 工单）。它不是最早的类似功能请求，但它仍然是开放的。大多数前辈都被贴上了“wontfix”的标签，这通常是好主意和坏主意棺材上的最后一颗钉子。
票证的目标是创建一个系统，允许一个插件需要一个或多个其他插件才能运行。依赖关系在编程世界中并不是什么新鲜事。 Composer，标准的 PHP 包管理器，还有两周就满 10 岁了。在 JavaScript 方面，npm 已经存在了 12 年，WordPress 在其核心代码中大量采用了它。
不过，这些都是开发者工具。 WordPress 是为用户构建的，解决插件依赖关系需要在用户界面中进行。
Mills 在工单中写道：
自从我们查看插件依赖关系以来已经有几年了，这似乎仍然是人们真正非常想要的功能，尤其是对于本身不是插件的共享功能。例如，一个 PHP 库在核心中不够流行，但足够流行以捆绑在多个插件中。
这句话在今天可能更有意义。在过去的十年中，许多插件都发展了自己的附加插件生态系统。确保安装依赖项的责任通常落在最终用户的肩上。开发人员已经提出内部解决方案来减轻这种负担，TGM 插件激活脚本已成为事实上的标准。
任何插件项目几乎都需要依赖项，至少在一般构建工具设置中是这样。可以肯定地说，与 WordPress 形成时期相比，如今更多的 WordPress 插件开发人员更愿意在需要第三方代码的环境中进行编码。
对于一个一直在努力自我现代化的平台来说，解决插件依赖关系就像乘坐火箭飞船去狂野的西部一样。
这个想法在 WordPress 世界中并非没有先例。虽然这是一个不太复杂的情况，但从目录安装子主题时，WordPress 会自动下载并安装父主题。
插件依赖系统的很多参数都是额外的方案。最明显的用例是 WooCommerce 和为它编写的许多扩展。
但是，另一种可以深入了解开发人员如何在 WordPress 之上构建的场景是包含框架和库。插件作者现在必须在他们的项目中捆绑第三方代码，并确保如果它已经捆绑在一个完全独立的插件中则不会被加载。
代码重用是编程的基石之一。目前，没有捆绑代码库或脚本的标准。此外，WordPress 插件目录不允许使用新的框架和类似的库。
为了透明起见，我至少有十几个属于这一类的项目，其他人可以使用的包。所以，我至少在游戏中有一些皮肤，而且我相信很多其他人都在同一条船上。
插件依赖系统的 WordPress GitHub 存储库中有两个拉取请求。还有一个 Google Docs 文档详细概述了这两个提案。
每个提案都要求开发人员通过插件标头定义依赖项。这是一个需要 WooCommerce 和 Gutenberg 的示例：
两种方法都相似。从用户的角度来看，他们将：
- 向管理员显示需要安装依赖项的通知。
- 不允许删除或禁用插件而不删除或禁用他们需要的插件。
- 在管理插件屏幕上的插件卡中放置一条消息。
第一个实现是由 Ari Stathopoulos 编写的。它创建一个“激活队列”，其中仅在用户激活所需插件后才激活插件。它还允许用户取消激活请求。
开启依赖通知。
Andy Fragen 的解决方案在插件管理屏幕上创建一个新的“依赖项”选项卡。这种方法会自动停用任何具有未满足依赖关系的插件，并通过管理员通知通知用户。
他还在 GitHub 上为单独的项目发布了插件依赖项选项卡。
插件依赖选项卡。
两者仍然存在一些实际问题。也就是说，当支持的版本之间存在冲突时会发生什么？目前的提议是让插件不要破坏用户端的任何东西。
这可能是所有这一切中最不鼓舞人心的部分。然而，这可能是最实用的路线。此外，WordPress 不解决其当前 Wild West 系统中的版本冲突。
依赖项解析也可能是实现更多代码现代化的机会。欢迎看到更多开发人员采用接口（合同）等功能。考虑到依赖性进行编码意味着以不同于任何给定项目是独立插件时的方式来思考架构问题。
出处
