Coding Standard Laravel Package

Technical Evaluation

Architecture fit. keboola/coding-standard is not a runtime library — it is a PHP_CodeSniffer ruleset (a ruleset.xml plus a Composer manifest) that layers Keboola's conventions on top of PSR-12 and Slevomat. It operates entirely at the tooling layer, so it is orthogonal to application architecture and framework internals. It will slot into a Laravel codebase without touching autoloading, service providers, or runtime behavior. Release 16.1.0 does not change this: the only substantive change is a dependency constraint update.

Integration feasibility. High. The integration is a composer require --dev keboola/coding-standard, a phpcs.xml.dist with <rule ref="Keboola"/>, and dealerdirect/phpcodesniffer-composer-installer to register the standard. A competent PHP developer can validate it in an afternoon against a single module.

Technical risk. Low at runtime, moderate at the governance layer. The package signals are weak: 1 star and 0 dependents implies it is maintained primarily for Keboola's own repositories rather than as a community standard. The recent release cadence (16.0.0 → 16.1.0, with 16.1.0 dated 2026-01-23) is reassuring evidence of active internal use, but the bus factor is still effectively one organization. 16.1.0 is a minor bump whose sole change is the php_codesniffer version requirement — that is a maintenance signal, not a capability signal, and it also means our own pinned PHPCS version now has to be re-checked against upstream intent. Mitigation remains cheap: pin exact versions in composer.json, and be prepared to vendor or fork the ruleset XML — it is MIT-licensed and mostly declarative configuration, so the fork cost is hours, not weeks.

Key questions.

• Which direction did the php_codesniffer constraint move in 16.1.0? The changelog names the PR but not the change. Read composer.json on the 16.1.0 tag to determine whether the minimum was raised, the range widened, or PHPCS 4.x support was added — each has a different implication for our pinned version.
• What PHP version matrix does the ruleset target, and does the new PHPCS constraint conflict with our existing squizlabs/php_codesniffer requirement?
• Does it ship a baseline/exclusion mechanism for legacy code, or do we need phpcs-baseline or a hand-maintained exclude list?
• How far does it diverge from PSR-12 and Laravel Pint defaults (tabs vs spaces, strict types, import ordering, trailing commas)? Divergence determines the size of the initial reformat diff.
• Is Keboola's internal standard a reasonable proxy for ours, or are we adopting someone else's opinions wholesale?

Integration Approach

Stack fit. Compatible with Laravel 10/11 and PHP 8.1+. The main friction is engine overlap: Laravel ships Pint (PHP-CS-Fixer under the hood) while this package targets PHPCS. Running both produces rule drift and contradictory auto-fixes. Pick one as the source of truth — either use Keboola/PHPCS for enforcement and restrict Pint to formatting only, or skip this package and encode equivalent rules in pint.json.

Migration path. Do not big-bang reformat. Sequence: (1) install on a branch and run phpcs against app/ only with the full report; (2) quantify violations by sniff to identify the expensive rules; (3) generate a baseline or exclude list for legacy files; (4) reformat per-directory in isolated PRs; (5) expand scope to tests/ and database/.

Compatibility. The 16.1.0 release makes this step more important, not less: the standard's supported PHPCS range has just moved, so resolve the PHPCS version first and let it constrain everything else. Run composer why-not keboola/coding-standard before committing, and confirm the resolved squizlabs/php_codesniffer version sits inside the range declared at the 16.1.0 tag. Slevomat versions pinned by the standard are the other likely conflict point against dev dependencies. Confirm the standard registers correctly under the Composer installer plugin and that CI images have the required PHP extensions (tokenizer, xml).

Sequencing. Sandbox validation, now including an explicit PHPCS-version check against the 16.1.0 constraint → non-blocking CI job → baseline commit → blocking gate on changed files only → full-repo gate. Keep the standard pinned and upgrade deliberately, not via composer update. Treat a future PHPCS major-version bump in this package as a planned mini-project rather than a routine dependency refresh.

Operational Impact

Maintenance. Day-to-day cost is near zero once configured. The real maintenance burden is version pinning and periodic review — budget a quarterly check for upstream releases and PHPCS major-version compatibility. 16.1.0 is exactly the class of release that justifies that cadence: small, non-breaking on its face, but it touches the dependency boundary the whole ruleset rests on. Because the package is community-thin, assign a named internal owner (a senior PHP engineer) who can fork the ruleset if upstream goes quiet. The MIT license and declarative format make that a low-severity contingency.

Support. No vendor SLA; GitHub issues only. Escalation path is internal. Document the adopted ruleset, the pinned PHPCS version, the rationale for any disabled sniffs, and the fork procedure in CONTRIBUTING.md.

Scaling. PHPCS is single-threaded by default; on a large Laravel monorepo, full scans will dominate CI time. Use phpcs --parallel and scope PR checks to changed files (--filter or a diff-based wrapper), with a nightly full scan. Exclude vendor/, storage/, bootstrap/cache/, and generated code to avoid false positives and wasted cycles.

Failure modes. A PHPCS major upgrade breaking the ruleset — now slightly more live a concern given the dependency constraint is actively moving; a wider range can silently resolve to a PHPCS version we have not tested. Also: a new upstream rule turning CI red without a code change; memory exhaustion on very large files; false positives on Blade-adjacent or generated PHP. All are addressable with pinned versions, a baseline file, and exclusion patterns.

Ramp-up. Half a day for anyone who has used PHPCS or Pint. Provide a composer lint / composer lint:fix script and a short README section so contributors do not need to learn the ruleset internals. The learning curve is in the team's conventions, not in this package.