PHPStan 2.1.12版本与PestPHP类型检查插件的兼容性问题分析

问题背景

PHPStan作为PHP静态分析工具的最新2.1.12版本发布后，与PestPHP的类型检查插件(pest-plugin-type-coverage)出现了兼容性问题。当用户尝试运行vendor/bin/pest --type-coverage命令时，会抛出类型错误。

错误现象

具体错误信息显示，在NodeScopeResolver类的构造函数中，传入的第11个参数类型不匹配。系统期望接收DeprecationProvider类型的参数，但实际接收到了AttributeReflectionFactory类型的参数。

技术分析

深入分析这个问题，我们需要理解几个关键点：

1. PHPStan的内部类NodeScopeResolver在2.1.12版本中修改了构造函数参数
2. PestPHP的类型检查插件直接实例化了这个内部类
3. PHPStan的向后兼容承诺不覆盖内部类的变更

根本原因

问题的核心在于PestPHP插件直接实例化了PHPStan的内部类NodeScopeResolver，而没有使用PHPStan推荐的依赖注入方式。PHPStan的内部类不在其向后兼容承诺范围内，因此可以在次要版本更新中进行破坏性变更。

正确的做法应该是通过PHPStan的容器系统获取服务实例，使用Container::getByType()方法来获取NodeScopeResolver实例，而不是直接实例化。

解决方案

对于遇到此问题的开发者，有以下几种解决方案：

1. 临时解决方案：将PHPStan锁定在2.1.11版本
2. 等待PestPHP插件更新：已有PR提交修复此问题
3. 自行修改插件代码：使用正确的服务获取方式

最佳实践建议

1. 在开发PHPStan扩展或插件时，避免直接实例化PHPStan的内部类
2. 始终使用PHPStan提供的容器系统获取服务
3. 关注PHPStan的向后兼容承诺范围，了解哪些API是稳定可用的
4. 对于内部类的使用要格外谨慎，因为它们可能会在不通知的情况下变更

总结

这次兼容性问题为我们提供了一个很好的案例，展示了为什么在开发扩展时应该遵循框架/工具提供的官方集成方式。直接依赖内部实现虽然有时看起来方便，但会带来长期的维护问题。PHPStan团队通过明确的向后兼容承诺，帮助开发者区分哪些API可以安全使用，哪些应该避免。