WP Packages：社区主导的开源 Composer 仓库来了
WP Engine 于 3 月 12 日收购 WPackagist 后，WordPress 开发者社区面临一个熟悉的问题：关键开源基础设施落入企业控制后会发生什么？实际上，社区早已在推进自己的答案。四天后，由 Roots 团队打造的 WP Packages（前身为 WP Composer）正式上线，成为完全独立、社区资助的替代方案——而且带来了多项技术升级。
事件背景：开源基础设施的所有权之变
WPackagist 由英国数字合作社 Outlandish 于 2013 年创建，服务 WordPress Composer 生态超过十年。近年来该项目饱受维护延迟、更新缓慢、社区参与不足等问题困扰。当 WP Engine 宣布收购时，开发者们立即担忧：一家私募股权支持的公司把控如此基础的工作流设施会带来什么风险？
值得注意的是，WP Engine 在收购完成后立即更新了 Composer info 字段，在每位开发者的终端中显示「WPackagist is now maintained by WP Engine」通知。虽是小事，却足以说明企业所有权如何改变工具与用户之间的关系。
技术优势：不仅更好，而且更快
Ben Word 其实早在去年八月就开始构建 WPackagist 替代方案，远早于收购新闻爆出。收购消息一出，他加速了发布进度，于 3 月 16 日正式上线，并全面开源了 GitHub 仓库。
性能提升显著：WP Packages 支持 Composer v2 的 metadata-url 协议，可仅获取项目实际需要的包元数据。WPackagist 则仍依赖旧的 provider-includes 方式，强制 Composer 在解析依赖前下载大型索引文件。实测显示，10 个插件的冷依赖解析：WP Packages 只需 0.7 秒，WPackagist 则需 12.3 秒——速度快约 17 倍。
其他关键改进：
- CDN 缓存 + 公共缓存头 + 不可变、内容寻址的独立包文件
- 包命名更简洁：
wp-plugin/和wp-theme/替代wpackagist-plugin/和wpackagist-theme/ - 元数据包含插件/主题作者、描述和主页 URL（WPackagist 缺失多年的功能）
- 更新同步周期：每 5 分钟（WPackagist 约 90 分钟）
迁移指南：三步切换到 WP Packages
第一步：移除旧包
composer remove wpackagist-theme/twentytwentyfive第二步：更换仓库地址
composer config --unset repositories.wpackagist
composer config repositories.wp-composer composer https://repo.wp-packages.org第三步：使用新命名安装包
composer require wp-theme/twentytwentyfive嫌麻烦？使用官方迁移脚本一键完成：
curl -sO https://raw.githubusercontent.com/roots/wp-packages/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.sh使用 Bedrock 搭建的项目开箱即已配置好 WP Packages。Roots 还提供了 WP Packages Changelog Action，可集成到 GitHub Workflows 中追踪依赖更新。
透明承诺：永不利用终端推送商业信息
WP Packages 的全部内容——应用代码、文档、甚至完整的 Ansible 部署配置——均在 GitHub 上公开，任何人都可以 Fork 并运行自己的 WordPress Composer 镜像仓库。
更重要的是，Ben Word 公开承诺：WP Packages 永远不会通过 Composer info 字段向开发者终端推送消息、广告或推销内容。这种克制在向社区负责而非企业母公司的项目中更容易兑现。
项目通过 GitHub Sponsors 获得资助，现有赞助商包括 Carrot、Kinsta、WordPress.com 和 Itineris 等。
