Coding Standards Laravel Package

Product Decisions This Supports

• Engineering quality gate: Supports adopting a shared PHP_CodeSniffer ruleset as part of the definition of done for Laravel/PHP services, reducing style and consistency review churn.
• Build vs. buy/adopt: Suggests a low-cost “adopt and pin” approach rather than building an internal ruleset from scratch—unless the team needs custom Vanio-specific conventions or long-term ownership.
• Developer experience roadmap: Fits CI standardization, repo templates, pre-commit hooks, IDE configuration, and onboarding checklists for PHP teams.
• Use cases: Greenfield Laravel APIs, internal services, package/library templates, monorepos, and legacy codebases where incremental lint enforcement is practical.
• Not a customer-facing feature: This is engineering productivity infrastructure. Its product value is consistency, lower review overhead, and fewer avoidable defects—not differentiation.

When to Consider This Package

• Consider it when the team already standardizes on PHP_CodeSniffer and wants an opinionated, lightweight ruleset for Laravel/PHP repositories.
• Consider it for a pilot on one or two internal repos where the team can pin the dependency, test PHP/Laravel version compatibility, and compare results against existing standards.
• Consider it if the organization is willing to fork or vendor the ruleset if maintenance stalls, and if the rules align with team conventions.
• Look elsewhere if the team uses Laravel Pint / PHP-CS-Fixer as the primary formatter, needs active community support, broad adoption, documented rule rationale, or long-term maintenance guarantees.
• Look elsewhere for public packages or distributed libraries where coding-standard dependencies should remain minimal and well-supported. With 0 stars and 0 dependents, treat this as a small, replaceable tooling dependency—not a strategic platform choice.

How to Pitch It (Stakeholders)

Executives: This is a low-cost engineering productivity guardrail, not a revenue-driving product feature. It can standardize PHP code quality in CI and reduce review churn, but its low adoption signals mean we should pilot it, pin it, and avoid making it a strategic dependency. Success should be measured by reduced review comments, faster onboarding, and fewer style-related CI surprises.

Engineering: Trial it as a pinned dev dependency in CI and pre-commit hooks. Compare its rules against existing Laravel Pint/PSR-12/PHP_CodeSniffer configurations before standardizing. Because adoption is essentially zero, assume maintenance risk and be prepared to fork or replace it. Use it only where PHP_CodeSniffer is already the chosen tool; otherwise stay with the team’s existing Laravel formatting stack.