Code Style Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for code standards. Authoring 16+ custom PHPCS sniffs (formatting, control structures, naming, imports, class structure, security) is typically several weeks of engineering plus indefinite maintenance. Adopting this is the cheap path — provided the opinions fit.
• Org-wide standardization across a portfolio of Laravel repos. One ruleset, one phpcs.xml, one CI job. Shifts review feedback from subjective style arguments to actual design discussion.
• Roadmap prioritization of tech-debt interventions. If style drift, inconsistent naming, or stray die/exit/var_dump/print_r in production paths are recurring defect sources, a lint gate is a low-cost, non-architectural fix that doesn't compete with feature work.
• Onboarding and vendor/contractor governance. Encodes "how we write PHP" as executable policy rather than a wiki page that rots.
• A concrete tooling decision: PHPCS + custom sniffs vs. Laravel Pint. This package presupposes the former. That's the real decision on the table, not the package itself.
• Best-fit use cases: internal product repos, agency client deliverables, packages within the ArtisanPack UI family, and teams with mixed seniority and no existing formatting consensus.

Treat the house-style choices — tabs, spaces inside parentheses (if ( $condition )), Yoda conditionals, uppercase magic methods (__CONSTRUCT()) — as brand/team preference decisions, not quality decisions. They are the package's identity and its adoption friction in equal measure.

What's genuinely differentiated, and worth valuing separately from the cosmetics:

• Laravel-aware TypeDeclaration sniff that skips property checks for Model classes and Models directories. Generic PSR-12 rulesets get this wrong and produce noise developers learn to ignore.
• Security sniffs covering input validation and output escaping — rare in a style standard, and the piece most defensible as a "buy" rather than "build."
• Per-sniff configurability (ArtisanPackUI.Formatting.Indentation with an indent property), which makes partial or tuned adoption technically feasible.

When to Consider This Package

Adopt when:

• You own the codebase and CI end-to-end and have no entrenched standard, or are willing to run a migration PR.
• You want Laravel-specific rules that don't fight Eloquent.
• Security linting is part of your value proposition, not just formatting.
• You're inside or adjacent to the ArtisanPack UI ecosystem — the ruleset name, docs structure, changelog, and release cadence all read as maintained-for-that-family.
• You want a forkable base rather than a black box; the sniff-level addressing makes that practical.

Look elsewhere when:

• PSR-12 compliance is a hard requirement — interop, OSS contribution, framework packages, or acquirer due diligence. Tab indentation, paren spacing, and uppercase magic methods will conflict with external tooling and outside contributors.
• You already use Laravel Pint. Running both creates conflicting auto-fixes and a CI arms race.
• You need ecosystem durability. 0 stars, 0 dependents, effectively single-maintainer, and a GitLab issue tracker linked from a GitHub repo. That's a bus-factor and discoverability risk for something your whole org inherits.
• Your goal is formatting-only enforcement. LineLength is explicitly disabled, and formatting is a commodity better served by a maintained tool.
• You need deep Blade/template coverage. Only control-structure style is addressed.

Adoption criteria before committing: pinned version, a CI job that actually fails the build, a documented migration PR, a named owner, and an escape hatch — rule-level exclude entries for legacy code you won't fix this quarter.

How to Pitch It (Stakeholders)

Executives. A single MIT-licensed dev dependency that turns "our code style" into something CI enforces, instead of a document nobody reads. The cost is one line in composer.json and one CI step; the return is fewer review cycles burned on nitpicks and less drift across repos and contractors. The risk is concentration: this is a small, near-zero-adoption project. Frame it as an internal convention with a fork option, not a strategic platform bet — and budget the fork cost if it goes org-wide.

Engineering. A PHPCS ruleset with 16+ custom sniffs spanning formatting, code structure, naming, type declarations, import ordering, class structure, disallowed functions, and security checks. It's Laravel-aware — TypeDeclaration skips property-type checks in Models so it won't fight Eloquent. Every sniff is overridable via phpcs.xml properties, so indentation width and rule selection are tunable. Requires PHP 8.2+.

The caveat to lead with, not bury. This is an opinionated house style, not a community standard. Tabs, space-inside-parens, Yoda conditionals, and uppercase magic methods will be contentious in review, and they diverge from PSR-12 and Pint. Recommended path: pilot on one internal repo with a timeboxed migration PR, measure how many violations are autofixable vs. manual, then decide. Do not apply it to repos where outside contributors or PSR-12 compliance matter — the friction there outweighs the benefit.