WordPress Playground 项目中包依赖问题的分析与解决

问题背景

在 WordPress Playground 项目中，用户在使用自定义 GitHub Action 进行性能测试时遇到了一个包依赖问题。具体表现为当从 1.0.12 版本升级到 1.0.13 版本后，系统报错无法找到 @wp-playground/wordpress-builds 包。

错误现象

当用户直接调用 ./node_modules/@wp-playground/cli/wp-playground.js server 时，系统抛出模块未找到的错误：

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@wp-playground/wordpress-builds' imported from /home/runner/work/wp-performance-action/wp-performance-action/env/node_modules/@wp-playground/blueprints/index.js

问题分析

经过技术团队分析，这个问题源于以下几个技术点：

1. 依赖关系变更：在版本升级过程中，Blueprints 包与 WordPress builds 包之间建立了新的依赖关系
2. Nx 构建问题：Nx 在生成最终的 package.json 文件时，未能正确包含 @wp-playground/wordpress-builds 作为依赖项
3. 包可见性问题：@wp-playground/wordpress-builds 在 Playground 仓库中被标记为私有(private)，这可能导致依赖解析出现问题

临时解决方案

在等待正式修复期间，用户可以采取以下临时解决方案：

1. 手动安装缺失的包：@wp-playground/wordpress-builds 实际上已经发布在 npm 上，可以单独安装
2. 回退到稳定版本：暂时使用 1.0.12 版本以避免此问题

根本解决方案

技术团队提出了以下长期解决方案：

1. 重构版本检测逻辑：不再使用 web 构建版本作为 WordPress 最新版本的代理，而是直接从 WordPress 官方 API 获取版本信息
2. 修正依赖声明：确保所有必要的依赖项都正确声明在 package.json 中
3. 改进构建流程：优化 Nx 的构建配置，确保所有依赖都能被正确包含

问题修复

该问题最终通过代码合并得到解决，主要变更包括：

1. 移除了对 @wp-playground/wordpress-builds 的不必要依赖
2. 实现了直接从 WordPress 官方 API 获取版本信息的新机制
3. 确保了构建系统的稳定性

经验总结

这个案例展示了在复杂 JavaScript 项目中依赖管理的重要性，特别是在使用 monorepo 架构和自动化构建工具时。开发者需要注意：

1. 跨包依赖关系的明确定义
2. 构建工具配置的准确性
3. 版本升级时的兼容性检查
4. 私有包与公共包之间的依赖关系处理

通过这次问题的解决，WordPress Playground 项目的构建系统得到了进一步优化，为未来的开发奠定了更坚实的基础。