Coding Standard Laravel Package

Product Decisions This Supports

This is a developer-tooling decision, not a product-feature decision — it ships no runtime code, so its value shows up as engineering velocity, review quality, and static-analysis ROI rather than in the roadmap itself. The PM-relevant decisions it informs:

• Standardize-vs-drift on code style across repos. A one-line composer require plus ->withPreparedSets(symplify: true) gives an opinionated baseline for array formatting, method chaining, constructor parameter layout, and docblocks. This is a genuine "buy vs. build vs. tolerate inconsistency" call, where "build" means writing and maintaining custom fixer rules.
• Static-analysis adoption (PHPStan/Larastan) cost. Roughly ten of the 23 rules are docblock-hygiene fixers — adding missing @param/@var names, fixing name typos, reordering @param $x string → @param string $x, removing dead params. If the team's plan includes tightening Larastan levels, these rules mechanically clear a whole class of baseline noise before the human work starts. That is a measurable scope reduction on a technical-debt initiative.
• Diff noise and merge-conflict reduction. StandaloneLineConstructorParamFixer, StandaloneLinePromotedPropertyFixer, and StandaloneLineInMultilineArrayFixer are explicitly framed around easing git diffs when a new dependency is added. Direct benefit to teams with large PRs and parallel feature branches.
• Onboarding and review load. RemovePHPStormAnnotationFixer and RemoveUselessDefaultCommentFixer strip IDE-generated scaffolding that reviewers waste cycles on; a consistent standard also shortens the "what style do we use here?" conversation for new hires.
• CI gating policy. vendor/bin/ecs (dry-run) as a required check, --fix as a pre-commit or bot step — the standard becomes enforceable rather than aspirational.
• Dependency-health triage. The package is deprecated and the repo is archived, with 0 dependents and an "opportunity" score of 26.4 against an overall score of 8.2. That gap is the real signal: technically competent, strategically low-value to build around. The decision this drives is "adopt ECS's bundled set, not this package as a dependency."

When to Consider This Package

Reasonable to consider when:

• The team has already committed to ECS (symplify/easy-coding-standard) as its style runner. In that case this is the prepared set ECS now bundles — adopting it costs nothing extra.
• The codebase is a legacy or long-lived Laravel app with heavy docblock rot and an active PHPStan/Larastan hardening effort. The docblock fixers are the strongest, most differentiated part of the set.
• You need merge-friendly formatting rules (constructor params, promoted properties, one-item-per-line arrays) that mainstream presets don't cover.
• You want a zero-configuration trial: run it dry, read the diff, decide.

Look elsewhere when:

• The project is greenfield Laravel. Use Laravel Pint — first-party, maintained, zero-config, and the default most Laravel engineers already expect. Adding ECS + a deprecated set to a new app is unjustifiable friction.
• You need a maintained dependency. Archived means no security patches, no bug fixes, and no guarantee of compatibility with future PHP versions. Pin the version and treat it as frozen, or fork the handful of fixers you actually want.
• You need Laravel-specific rules (blade, facades, config conventions) — this set is framework-agnostic PHP, not Laravel-aware.
• The team's real need is automated refactoring (typed properties, promoted constructors, PHP 8.x migrations). That's Rector's job; a formatter won't do it.
• Your CI is already stable and style debt is low — the marginal gain won't repay the added toolchain.

How to Pitch It (Stakeholders)

To executives (one paragraph): "There's a low-cost, low-risk engineering hygiene tool that mechanically cleans up code formatting and docblock annotations, which in turn makes our static-analysis investment cheaper and cuts reviewer time on style nits. It's free (MIT), installs as a dev-only dependency, and touches no production code. Two caveats: the underlying package is officially deprecated and archived, and our new Laravel projects should use Laravel's own Pint tool instead. So the recommendation is narrow: evaluate ECS's bundled version of this rule set on one legacy repo for a sprint, measure the diff volume and static-analysis baseline reduction, and decide. If results are good, we adopt the maintained path (ECS or PHP-CS-Fixer), not this package directly. If we can't get a maintained path, we fork the five or six rules that actually pay off rather than taking an unmaintained dependency."

To engineering: "A 23-rule fixer set covering array layout, method chaining, promoted properties/constructor params, strict-types spacing, and — most usefully — ten single-purpose docblock repair rules (missing param names, name typos, switched type/name order, dead @param lines, superfluous @var/@return names, PhpStorm junk). Each rule does one thing, is individually tested, and handles @phpstan-/@psalm- prefixed variants. It runs best under ECS via withPreparedSets(symplify: true), dry-run by default, --fix to apply. But: the repo is archived and the README tells you to use ECS instead — so the real proposal is 'adopt ECS's prepared set' or 'port the docblock fixers into our existing PHP-CS-Fixer/Pint config.' Spike it on one branch, read the diff, and check whether the fixers are reusable outside ECS before we commit to the toolchain."