Coding Standard Laravel Package

Technical Evaluation

Architecture fit: eve/coding-standard is a development-time PHP_CodeSniffer ruleset, not a runtime Laravel package. It has no application architecture coupling, no service provider, no database or queue impact, and no production deployment footprint. For a TPM, that makes it a low-blast-radius candidate for standardizing Laravel/PHP code style in CI. However, with 7 stars, 0 dependents, and a last release in April 2021, it should be treated as a reference ruleset or a fork candidate rather than a long-term upstream dependency.

Integration feasibility: Integration is straightforward in principle: add as a Composer require-dev dependency, create a phpcs.xml ruleset, and run vendor/bin/phpcs in local hooks and CI. The main feasibility question is version compatibility: the package likely targets PHP_CodeSniffer 3.x and PHP 7.x/early 8.x conventions. Modern Laravel teams often use Pint/PHP-CS-Fixer, so adopting this package may create duplicate tooling unless the team deliberately standardizes on PHPCS.

Technical risk: Low security risk because it is dev-only tooling. Moderate delivery risk because the package is stale and effectively unmaintained: no recent releases, no dependent ecosystem signal, and unknown compatibility with PHP 8.1+, PHP 8.2+, Laravel 10/11, and PHP_CodeSniffer 4.x. The largest risk is CI friction from false positives or Composer resolution conflicts, not production failure. A fork or internal wrapper is likely required if the standard is adopted beyond a pilot.

Key questions:

• Which PHP, Laravel, PHP_CodeSniffer, and Slevomat/coding-standard versions are supported?
• Does the ruleset include custom sniffs, or only configuration over upstream standards?
• Is it PSR-12/PER aligned, and how does it differ from Laravel Pint defaults?
• What is the license and fork/maintenance policy?
• Are there known conflicts with PHP_CodeSniffer 4.x or PHP 8.2+?
• Who owns upgrades and exception handling if the upstream remains inactive?

Integration Approach

Stack fit: Fits a Laravel/PHP stack as a Composer dev dependency and CI quality gate. It should not be introduced as an application dependency. Best fit is a team that already uses PHP_CodeSniffer or wants a Laravel-oriented ruleset as a starting point. Poor fit if the team has standardized on Laravel Pint and does not want a second style tool.

Migration path: Start with a single repository pilot. Install as require-dev, run PHPCS in report-only mode, and baseline existing violations. Fork the ruleset internally if upstream constraints block PHP or PHPCS upgrades. Once stable, publish as a private Composer package or path repository and roll out repo by repo.

Compatibility: Verify against the team’s PHP matrix, Composer 2, PHP_CodeSniffer version, and CI image. Expect to pin transitive dependencies. Since the last release is 2021, assume Laravel 10/11 and PHP 8.2+ are unverified until proven in the pilot. If Pint is present, decide explicitly whether PHPCS replaces it, complements it, or is limited to custom sniffs.

Sequencing:

1. Spike in one repo with a pinned PHPCS version.
2. Run report-only and measure violation volume and false-positive rate.
3. Decide fork vs. direct dependency.
4. Define CI enforcement scope: changed files first, then full repo.
5. Publish internal ruleset package if multiple repos are in scope.
6. Roll out to additional repos with a documented exception process.

Operational Impact

Maintenance: Upstream maintenance is effectively absent. The TPM should budget for an internal owner to pin versions, review PHPCS upgrades, and maintain a fork if adoption grows. Maintenance effort is modest but not zero.

Support: No vendor support and little community signal. Support must be internal: documented installation, rule rationale, suppression policy, and escalation path. Developer questions will likely concern false positives and IDE integration.

Scaling: Scales acceptably across repositories if centralized as a private Composer package. CI runtime is typically seconds to low minutes depending on codebase size; caching Composer and limiting to changed files improves feedback loops. Scaling risk is governance, not infrastructure: inconsistent adoption and untracked exceptions.

Failure modes: Composer dependency conflicts, PHPCS incompatibility with newer PHP versions, false positives blocking CI, drift from Pint/PHP-CS-Fixer, and upstream abandonment. None are production outages, but they can degrade developer experience and slow delivery if enforcement is too aggressive too early.

Ramp-up: Low for PHP developers familiar with PHPCS; moderate for teams standardized on Pint. A short onboarding note, IDE setup, and a baseline suppression strategy are enough. TPM should set expectations that this is a starting-point ruleset, not a maintained industry standard.