如何删除或下线Composer私有仓库中废弃的扩展包-composer-PHP中文网

应使用 composer remove 命令卸载包，它自动移除 composer.json 条目、删除 vendor 目录、更新 lock 文件并重建 autoload；切勿手动删文件，否则易导致 autoload 失效或 ci 构建失败。

如何删除或下线composer私有仓库中废弃的扩展包

私有仓库里删不掉包？先确认仓库类型和权限

Composer 私有包无法直接“删除”，因为 Composer 本身不提供包删除功能——它只是个依赖解析器，真正的包存储和管理由底层仓库系统决定。你看到的 composer require vendor/name 能安装，是因为 Composer 从配置的仓库（如 Satis、Packagist Private、GitLab Package Registry、GitHub Packages 或自建 Artifactory）拉取元数据和 ZIP/tarball。所以第一步必须明确：你的私有仓库用的是哪一种？不同系统操作路径完全不同。

常见情况包括：

用 satis 搭建的静态仓库：删的是 packages.json 中的条目 + 对应 dist 文件，再重新 build
用 GitLab/GitHub 的原生 Package Registry：需调用 API 或在 UI 中手动“delete package”（注意：GitHub Packages 默认不允许删除，需开启 allow_deletion）
用 Nexus/Artifactory：进 Web UI 找到对应 vendor/name 的版本，选中后删除；或用 REST API 发送 DELETE 请求

使用 Satis 时如何真正“下线”一个废弃包

Satis 不支持运行时删除，它的 packages.json 是静态生成的快照。想让某个包彻底不可见、不可安装，必须从源配置中移除，并重建整个仓库。

实操步骤：

检查 satis.json 中的 repositories 列表，确认该废弃包是否还在其中（比如以 git 类型引用了某个已归档的仓库）
若该包是通过 require 显式列出的（Satis 支持 "require": {"vendor/old-package": "1.0.0"}），直接删掉这行
运行 php bin/satis build satis.json web/ 重新生成 packages.json 和 dist 文件
同步更新 Web 服务器上的静态文件（注意 CDN 缓存，可能需要 Cache-Control: no-cache 或强制刷新）

⚠️ 注意：composer clear-cache 在客户端执行无效——旧包的 ZIP 文件只要还留在 web/dist/ 下，就仍可能被直接下载。务必确认 dist 目录中对应 vendor-old-package-1.0.0-zip-hash.zip 已被清除。

GitLab Package Registry 删除包的实际限制

GitLab 15.0+ 支持通过 UI 或 API 删除 Composer 包，但有两个关键前提：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

项目可见性必须是 private 或 internal（public 项目不支持删除 Composer 包）
用户需有 Maintainer 权限及以上，且项目启用 packages_and_registries 功能

删除命令示例（需替换 PROJECT_ID、PACKAGE_ID 和 PRIVATE_TOKEN）：

curl --request DELETE \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  "https://gitlab.example.com/api/v4/projects/<project_id>/packages/<package_id>"</package_id></project_id></your_access_token>

获取 PACKAGE_ID 需先查列表：GET /projects/:id/packages?package_type=composer。别跳过这步——直接硬删会返回 404 或 403，不是接口错了，是 ID 没找对。

下线 ≠ 彻底消失：客户端缓存与 packagist.org 的干扰

即使服务端已清理干净，开发者本地仍可能成功 composer install 到旧包。原因有二：

Composer 默认启用本地缓存，~/.composer/cache/files/vendor/old-package/ 下的 ZIP 还在，会直接解压复用
如果你曾把该包提交到 public packagist.org（哪怕只是一次 composer submit），它就会永久保留在那里，且无法删除（Packagist 不允许删包）

应对方式：

提醒团队运行 composer clear-cache，或手动 rm -rf ~/.composer/cache/files/vendor/old-package
检查 packagist.org/packages/vendor/old-package 是否存在——如果存在，只能在 composer.json 中加 "abandoned": true 并指向新包，这是 Packagist 唯一认可的“软下线”方式

最常被忽略的一点：很多团队以为改了 satis.json 就完事，却忘了 CI/CD 流水线里还有自动 build 任务——那个旧包可能每晚都在悄悄重建。去翻下你的 CI 配置，确认 build 触发逻辑是否真的切断了源头。