Coding Standard Laravel Package

Technical Evaluation

Architecture fit. Unchanged in principle: libero/coding-standard is a development-time PHP_CodeSniffer ruleset, not a runtime library, so it has no production footprint and no runtime attack surface. What v0.5.0 changes is the substance of the artifact. Eight new rules in a single release — array initialization before use, no late static binding in final classes, static closures, ternary simplification, shorthand types, trailing commas, no redundant final methods in final classes, no unnecessary semicolons — is the release cadence and content of a maintained internal convention, not a frozen 2019 snapshot. The architectural slot it fills (a codified style policy wired into composer.json scripts and CI) is unchanged; the question of whether the policy is worth having now has a different answer.

Integration feasibility. Mechanically still trivial: composer require --dev libero/coding-standard, reference the ruleset from phpcs.xml, add a Composer script and a CI step. The friction remains in the constraints, and v0.5.0 does not resolve it — the release notes describe rules, not a PHP or PHPCS version bump. That omission is the single most important thing to check: a release that adds "late static binding must not be used for constants" and "final methods must not be used in final classes" is reasoning about PHP 8.1 final constant semantics, which implies the sniffs have been touched for modern PHP. But the notes do not state that squizlabs/php_codesniffer moved off the 2019 pin, and they do not state the php constraint. Until the composer.json diff between the previous tag and v0.5.0 is read, the PHP 8.2/8.3 viability question is open.

Technical risk. Materially lower than assessed previously, in two respects. First, an active maintainer means the "abandoned transitive pin blocks a tooling upgrade" risk and the "no upstream CVE response" risk are reduced from structural to ordinary. Second, several of the new rules — static closures, trailing commas in multi-line arrays, shorthand array syntax — demonstrate that the maintainer is tracking modern PHP idioms rather than preserving a 2019 fossil.

New risks introduced by this release, however:

1. Rule churn on a 0.x version. Under semver, 0.5.0 may break at any minor bump, and for a lint ruleset every rule addition is a breaking change for consumers: CI that was green becomes red with no code change. Eight new rules landing at once means a large immediate diff for any adopter.
2. Opinionated rules that will be contested. "Shorthand types must be used," "semicolons must not be used unnecessarily," and the ternary rules are style preferences, not correctness rules. Some are defensible; some will be argued about. A gate built on contested rules gets suppressed.
3. Overlap, not addition. Most of v0.5.0 is already expressible in php-cs-fixer / Pint (static_lambda, trailing_comma_in_multiline, array_syntax: short). That reduces the case for installing the package and increases the case for harvesting the rules — the value is the opinion set, not the implementation.
4. Verification debt. Still no signal here about dependents, stars, PHPCS 4.x readiness, or whether the custom sniffs use removed APIs.

Key questions.

• What changed in composer.json between the previous tag and v0.5.0? Specifically: did the php constraint move to ^8.x, and did the squizlabs/php_codesniffer pin move toward 4.x?
• Are the eight new rules implemented as custom sniffs, or as <rule ref="..."> entries delegating to upstream PHPCS/Slevomat sniffs? Delegation is a strong signal of quality and lowers porting cost to near zero.
• Which of the eight are already covered by our Pint config, and which are genuinely additive? My prior is that static closures, trailing commas, and shorthand arrays are already covered; "arrays created before use," the ternary rules, and the anti-redundancy rules around final classes are the plausibly additive ones.
• Do the new sniffs have tests? A ruleset with a test suite is a different adoption proposition from one without.
• Is there a published changelog or upgrade guide, and does the maintainer treat rule additions as breaking? How do they expect downstream CI to absorb a minor bump?
• Who owns this internally if we fork, and what is the retirement trigger?

Recommendation. Downgrade "do not add" to "re-evaluate with a time-boxed spike." v0.5.0 is credible evidence that this is a maintained, opinionated standard with real content, and the earlier "2019 archived snapshot" verdict is no longer safe to carry forward unexamined. Run a two-to-three day spike: read the constraint diff, install into one non-critical Laravel repo, and run in report-only mode against a PHP 8.2/8.3 codebase. The likely landing zone remains "extract the rules we agree with onto a maintained base," but that is now a conclusion to be earned by the spike rather than asserted.

Integration Approach

Stack fit. Unchanged tension. Laravel has a first-class answer in Pint plus phpcs.xml for what Pint cannot express. v0.5.0 sharpens the overlap problem — three of its eight rules duplicate fixers we already run — but it also clarifies the division of labour that would make adoption sane: let Pint own formatting (whitespace, commas, array syntax, static closures), and reserve PHPCS for the semantic rules Pint cannot do (arrays created before use, ternary shape, final redundancy). That split is worth designing regardless of whether this package is the vehicle.

Migration path. The extraction path is now more attractive than before, because the ruleset has more worth extracting:

1. Diff composer.json and ruleset.xml between the previous tag and v0.5.0 to see exactly what was added and how.
2. Check whether the new rules delegate to upstream sniffs. If they do, the "port" is a config change, not a code change.
3. Classify all rules into (a) already covered by Pint, (b) additive and agreed, (c) additive and contested, (d) obsolete.
4. Re-express (a) as confirmation, (b) in pint.json or a thin internal ruleset.xml extending PSR-12, and put (c) to a team vote — do not silently inherit someone else's opinion.
5. Baseline in report-only mode before enforcing.

If the spike shows clean installation on PHP 8.3 alongside Pint with no conflicts, a pinned dev dependency becomes a defensible alternative to forking — with the caveat in Operational Impact below.

Compatibility. This is the gating item and v0.5.0 does not answer it. Verify the PHPCS constraint first: if it still pins 3.x while the estate moves to 4.x, that ends adoption regardless of rule quality. Then run the tool over PHP 8.3 code containing enums, readonly properties, attributes, first-class callables, and constructor promotion — the new rules touch final classes and constants, which is exactly where PHP 8.1+ syntax will trip a stale tokenizer. Note also that the new rules will fire heavily on existing code; expect a large baseline diff.

Sequencing. Constraint diff → spike install on one repo → report-only baseline → classify rules with the team → port or pin → single isolated mass-format commit (no logic changes, added to .git-blame-ignore-revs) → CI gate → documentation. Two additions specific to this release: pin the exact version, not a caret range, because a 0.x lint ruleset can add rules in a minor; and review the ruleset on upgrade the way you would review a dependency bump, not the way you absorb a patch.

Operational Impact

Maintenance. Improved but conditional. An actively released ruleset with modern-PHP-aware rules is a maintainable artifact; the previous "zero cost until it becomes infinite" framing no longer holds. The residual burden is either near-zero (pinned dev dependency, upgrade deliberately each minor) or low-but-owned (fork with an explicit owner). What has not improved is the cost of absorption: v0.5.0 lands eight new rules at once, and any team already using the standard now faces a compliance pass. If we adopt, budget for that pass and don't let it ambush a release week.

Support. Upstream is alive, which is the single biggest change from the prior assessment. Release notes exist, issues are being closed with PR numbers, and there is a maintainer to ask. Caveats remain: it is a small project with a narrow user base, so "upstream will fix it" is a weaker guarantee than for a widely-adopted tool, and pre-1.0 versioning means the maintainer reserves the right to break us. Treat support as "best-effort, external, single-maintainer" and document the exit ramp.

Scaling. Same as before — a shared standard across N repos is the right pattern, and version skew is the failure mode. v0.5.0 adds a concrete skew vector: repos pinned before and after this release enforce different rule sets, so an identical PR passes in one repo and fails in another. Mitigate with one internal package, one version, and a policy that standards bumps ship as their own PR, reviewed, with the resulting diff applied repo by repo.

Failure modes. Carried forward, with updates:

1. Tooling deadlock — still possible if the PHPCS pin has not moved; check before adopting. Reduced likelihood.
2. Rule churn on minor bumps — new for this release. CI goes red on a dependency bump with no code change. Mitigate by exact-pinning and reviewing changelogs.
3. Syntax drift — reduced; the final-class rules imply modern PHP awareness, but the tokenizer risk is not eliminated until tested on 8.3.
4. Gate erosion — amplified. Contested opinion rules (semicolons, shorthand types, ternary shape) are the ones developers argue with, and argued rules get suppressed. Adopt only rules the team can justify.
5. Dual-tool conflict — Pint and phpcs fighting over commas, array syntax, and static closures is now a three-rule overlap, not a hypothetical.
6. Phantom authority — still the quiet killer; every inherited rule needs a one-line rationale in our docs.
7. Audit noise — an obscure dev-only dependency in SCA tooling; less concerning now that the project is alive, but keep the exception on file.

Ramp-up. Developer-facing cost stays near-zero: PHPCS output is familiar, the loop is composer lint:fix. Owner-facing cost rises slightly because there are now more custom rules to understand and defend. Organisational cost is unchanged and dominates: the mass-format commit, the quiet week afterwards for git blame and open PRs, and the low-merge-window scheduling. Add one item — a short written rationale per rule, including the eight new ones, so the standard has an owner's voice rather than an inherited one.

Bottom line for the TPM. v0.5.0 invalidates the "2019 archived snapshot" verdict that drove the previous recommendation. This is a maintained, opinionated standard with enough substance to be worth a deliberate look, but it is also pre-1.0, overlapping with Pint on roughly half its new rules, and still silent on the PHP/PHPCS constraints that decide feasibility. Fund a two-to-three day spike, decide on evidence, and record the outcome — either a pinned dev dependency with an upgrade policy, or an internal ruleset harvested under MIT. What should not happen is a wholesale install on the strength of the release notes alone, or a silent re-deferral that leaves the team with no shared standard.