Product Decisions This Supports
- Developer Experience (DX) Standardization: Enables consistent PHP code quality checks across projects by embedding phpcq (PHP Code Quality) into the Composer workflow, reducing friction for teams adopting new projects or enforcing standards in existing ones.
- Build vs. Buy: Avoids reinventing a custom CI/CD or pre-commit hook system for PHP static analysis, leveraging an open-source, battle-tested solution with minimal maintenance overhead.
- Roadmap Alignment: Supports initiatives like:
- "Shift Left" Quality: Integrating checks early in the dev cycle (e.g., pre-commit, CI gates).
- Onboarding Efficiency: Reduces ramp-up time for new engineers by automating quality checks via Composer (a tool they already use).
- Compliance/Standards: Enforces PSR, custom rules, or legacy codebase constraints without manual tooling setup.
- Use Cases:
- Monorepos: Uniformly apply quality checks across microservices or libraries.
- Open-Source Projects: Lower barrier to contribution by auto-configuring quality tools.
- Legacy Systems: Gradually introduce modern checks without disrupting existing workflows.
When to Consider This Package
- Adopt if:
- Your team uses Composer as the primary dependency manager and wants to avoid manual PHP-CS-Fixer/PhpStan/PHPMD setup.
- You need lightweight, declarative quality checks (not full CI replacements like GitHub Actions or Jenkins).
- Your project lacks a dedicated devops/engineering tools team to maintain custom scripts.
- You prioritize developer self-service (e.g., local pre-commit checks without CI delays).
- Look Elsewhere if:
- You require custom reporting or deep integration with existing CI/CD pipelines (e.g., Slack alerts, Jira tickets).
- Your team uses non-Composer workflows (e.g., npm/yarn for full-stack projects).
- You need advanced static analysis (e.g., type coverage, security scanning) beyond phpcq’s scope—consider PHPStan + Pest + Psalm stacks.
- Your project has strict compliance needs (e.g., HIPAA/GDPR) requiring auditable, centralized tooling (e.g., SonarQube).
- The package’s lack of stars/maintenance raises concerns about long-term viability (mitigate by forking or proposing contributions).
How to Pitch It (Stakeholders)
For Executives:
"This package lets us bake PHP code quality into our development workflow—like a ‘lint for humans’—without adding overhead. By embedding phpcq into Composer (a tool every developer already uses), we can catch style issues, potential bugs, and anti-patterns before they reach CI, saving engineering time and reducing technical debt. It’s a low-lift way to enforce consistency across teams, especially for open-source contributions or monorepos. Think of it as ‘autopilot for best practices’—minimal setup, maximum impact."
For Engineering:
*"This is a drop-in Composer plugin that installs and configures phpcq (a wrapper for tools like PHP-CS-Fixer, PhpStan, and PHPMD) with zero manual work. Key benefits:
- Pre-commit hooks: Run checks locally before pushing (configurable via
composer phpcq).
- CI-friendly: Lightweight enough for early-stage gates (e.g., fail fast on style issues).
- Extensible: Supports custom rules via
phpcq.yml—no need to maintain separate scripts.
- Future-proof: Aligns with modern PHP ecosystems (e.g., works with Laravel, Symfony, or standalone projects).
Downside: Early-stage package (0 stars), but the underlying tools are battle-tested. We can mitigate risk by [proposing a contribution/fork] if needed."*
For Developers:
*"No more ‘it works on my machine’ excuses—this auto-runs PHP code quality checks when you composer install. Fix style issues, dead code, or type errors before you commit. Just add this to your composer.json:
{
"require-dev": {
"phpcq/runner-bootstrap": "^1.0"
}
}
Then run composer phpcq to see issues. Want stricter rules? Edit phpcq.yml. It’s like ESLint for PHP, but built into Composer."*