企业官网建设流程全解析

composer-dependency-analyser如何「吃自己的狗粮」？快速依赖分析工具的自分析机制与贡献指南深度剖析

【免费下载链接】composer-dependency-analyser🚀 Fast detection of composer dependency issues (unused dependencies, shadow dependencies, misplaced dependencies)项目地址: https://gitcode.com/gh_mirrors/co/composer-dependency-analyser

composer-dependency-analyser（Composer 依赖分析器）是一个零 Composer 依赖的 PHP 静态分析工具，能在 2 秒内扫描 15000 个文件，快速检测项目中的未使用依赖（unused dependency）、影子依赖（shadow dependency）和错放依赖（misplaced dependency）。更值得新手学习的是：这个项目本身就是依赖分析的最佳实践——它用一套完整的"自分析（dogfooding）"机制检查自己的依赖健康度，并以此标准向贡献者保证代码质量。本文带你拆解它的自分析机制与贡献指南。

什么是"吃自己的狗粮"？

"Dogfooding"（吃自己的狗粮）指项目使用自己开发的工具来开发和维护自身。对一个依赖检测工具来说，这是最有力的质量保证：

• 自证可靠：如果工具连自己的 composer.json 都分析不了，用户凭什么信任它？
• 持续验证：每次提交代码都会触发自分析，依赖问题无法悄悄溜进主干。
• 配置示例：自分析配置文件本身就是给用户的最佳配置范例。

自分析机制：一个配置文件的四层设计

第 1 层：根目录自分析配置

项目根目录的 composer-dependency-analyser.php 就是工具分析自己时加载的配置，内容不到 30 行，却演示了核心 API：

• addPathToScan(__FILE__, true)：把配置文件自身也当作"开发路径"扫描（因为它是可执行代码）
• addPathToScan(bin, false)：把入口脚本目录作为生产路径扫描
• addPathToExclude(tests/data)：排除测试数据，避免误报
• ignoreErrorsOnExtensionsAndPaths(...)：精确忽略ext-dom、ext-libxml在 JunitFormatter 中的可选用法（代码里有extension_loaded()保护）

这种"按包 + 按路径 + 按错误类型"的组合忽略方式，正是 README 推荐的标准姿势，读者可以直接照搬到自己的项目。

第 2 层：composer scripts 中的 check:self

在 composer.json 的 scripts 里，一条composer check命令串联了 8 项检查，其中就有一条check:self：

"check:self": "bin/composer-dependency-analyser"

它直接运行工具本体，对本项目执行完整的依赖分析。一旦有人往 composer.json 添加了一个实际没用到的依赖，这条检查会立刻失败——依赖问题在 CI 阶段就被拦截。

第 3 层：零依赖的自举入口

入口脚本 bin/composer-dependency-analyser 内置了一个spl_autoload_register自动加载器，直接按 PSR-4 规则从src/目录加载自己的类，完全不依赖 composer 生成的 autoload。这意味着：

1. 工具自己就是"零外部依赖"的活广告，与其宣传口径完全一致；
2. 即使composer install不完整，自分析依然能跑起来；
3. 核心逻辑集中在 Analyser.php 与 UsedSymbolExtractor.php，CLI 参数解析独立在 Cli.php（还支持拼写纠错建议）。

第 4 层：用核心类约束覆盖率

coverage-guard.php 是测试覆盖率的"看门狗"，它直接引用了Analyser、Cli、Initializer、UsedSymbolExtractor四个核心类，并给它们设定了80% 的强制覆盖率（普通类 60%）。换句话说：核心代码没被测透，composer check:coverage就不通过。

更极致的 Dogfooding：把工具装进别人的项目里测试

自分析只是"小圈子"，这个项目的 e2e 测试玩得更彻底。scripts/refresh-e2e.php 会分页抓取 Packagist 上所有以require-dev依赖本工具、且月下载量超过 2000 的真实项目，过滤掉已废弃的包后，生成 CI 测试矩阵。

于是 CI 会把最新版工具安装进 phpstan、deptrac 等真实生产级项目里跑一遍分析。这相当于：工具每天都在全 PHP 生态的"实战考场"上考试，任何 API 不兼容、误报回归都会立刻暴露。

贡献指南：5 步成为合格贡献者

官方 README 的 Contributing 章节只有三行，却浓缩了全部要求：

# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/co/composer-dependency-analyser # 2. 安装开发依赖 composer install # 3. 自动修复代码风格 composer fix:cs # 4. 一键跑完全套检查（含自分析） composer check # 5. 编写测试：所有新功能必须被测试覆盖 composer check:tests

一键运行全套检查：composer check 命令清单

composer check依次执行 8 个子命令，新手可以对照 composer.json 逐一理解：

CI 质量防线：测试矩阵有多严？

.github/workflows/checks.yml 定义了双重防线：

• checks 任务：每个 PR 都在 PHP 8.5 上运行完整composer check；
• tests 矩阵：PHP 8.1 → 8.5 × prefer-lowest / prefer-stable × Ubuntu / Windows，共 20 种组合，确保最低版本依赖和最严环境都通过。

这解释了为什么它敢宣称兼容 PHP 7.2 - 8.5 且"零 Composer 依赖"——每一条宣传都有 CI 数据背书。

小结：从新手到贡献者的最短路径

1. 先跑：composer install后直接vendor/bin/composer-dependency-analyser分析自己的项目，零配置即可上手；
2. 再看：把根目录 composer-dependency-analyser.php 当活文档，学习ignoreErrors*、addPathToScan等配置 API；
3. 最后改：提交前确保composer check全绿（包含自分析），并为新功能补上测试。

一个分析工具最可信的推荐语不是广告词，而是"我们自己每天都在用它"。这正是 composer-dependency-analyser 值得借鉴的地方。

【免费下载链接】composer-dependency-analyser🚀 Fast detection of composer dependency issues (unused dependencies, shadow dependencies, misplaced dependencies)项目地址: https://gitcode.com/gh_mirrors/co/composer-dependency-analyser