Coding Standards Laravel Package

Product Decisions This Supports

• Coding-standard adoption for a Joomla extension portfolio (not Laravel applications). This package is the reference PHP_CodeSniffer ruleset for Joomla-style code. It answers a real governance question — "what does 'done' mean in code review, and can CI enforce it?" — but only inside Joomla's ecosystem.
• Backlog prioritization for a legacy modernization epic. Because the README states Joomla 4.2+ moved to PSR-12, adopting this ruleset actually signals "we are standardizing on a superseded convention." Use it as a decision input for retiring custom rulesets rather than adding one.
• Build vs. buy (or rather: build vs. adopt vs. ignore). Zero dependents, ~130 stars, and a last release in September 2020 are strong signals that the ecosystem has moved on. The correct product decision is usually "ignore, and adopt PSR-12 plus a maintained ruleset."
• Non-PHP linting scope. The one genuinely reusable asset is the bundled JavaScript/CSS standards, which the README explicitly says remain valid. This supports a tactical decision on front-end lint configuration for Joomla-adjacent themes and templates.
• Not a fit for Laravel feature work. For a Laravel product, this package informs nothing about application architecture, DX, or release cadence. Laravel teams should be pointed at Pint/Laravel preset and PSR-12 instead; the decision here is a rejection, and documenting the rejection (and why) prevents someone re-evaluating it next quarter.
• Licensing risk triage. GPL-2.0 on a developer tooling dependency warrants a short legal check before it enters a CI image that ships anywhere outside the org, even though running PHPCS locally is normally fine.

When to Consider This Package

Consider it only if all of the following are true:

• You maintain Joomla extensions, templates, or plugins — not a Laravel/Symfony/standalone PHP service.
• You are working on a Joomla 3.x or early 4.x codebase where the historical Joomla style (naming, docblocks, file structure) must be enforced for consistency with upstream contributions.
• You specifically need the non-PHP (JS/CSS) rulesets, which are the only parts the maintainers still describe as valid.
• You are contributing patches upstream to Joomla itself, where matching their house style is a hard requirement for merge.
• You can pin the dependency, accept a 2020-era ruleset running against modern PHPCS 3.x/4.x, and own any compatibility shimming yourself.

Look elsewhere if any of these are true:

• The codebase is Laravel, or any modern PHP 8.x application — the ruleset predates and conflicts with current practice; you will spend more time suppressing sniffs than fixing code.
• You need a maintained ruleset. Last release 2020-09-17, and the README's own "we will update this soon" note is now years stale — treat it as unmaintained for planning purposes.
• You want PSR-12 or PER Coding Style compliance — go directly to phpcsstandards/php_codesniffer with the PSR-12 standard, or Laravel Pint for Laravel.
• You need stricter modern static analysis — slevomat/coding-standard, PHPStan, or Psalm deliver far more value per engineering hour.
• Your organization cannot accept GPL-2.0 tooling in its build chain without legal sign-off.

How to Pitch It (Stakeholders)

Executive summary: This is a small, single-purpose developer tool — a linting ruleset, not a runtime library. It touches no customer-facing behavior, adds no runtime dependency, and carries no production risk. The decision is cheap to make and cheap to reverse.

The recommendation: Do not adopt this for our Laravel/PHP application work. The package is Joomla-specific, its last release was September 2020, and Joomla itself has since moved to PSR-12 — so we would be standardizing on a convention its own maintainers have deprecated. Zero downstream dependents confirm the ecosystem has moved on. Adopting it would create ongoing maintenance cost (patching an abandoned ruleset to work with current PHP_CodeSniffer) in exchange for enforcing a style we do not otherwise follow.

Where it earns a narrow yes: if we take on Joomla extension maintenance or upstream Joomla contribution, adopt it as a pinned require-dev dependency, scoped to that repository only, with the JS/CSS rulesets as the main prize. Budget roughly half a day to wire into CI, plus an owner for compatibility fixes.

What we do instead: standardize on PSR-12 plus Laravel Pint for application code, with PHPStan for depth. This is maintained, aligns with the wider PHP ecosystem, and requires no legal review.

For engineering: the package is a PHP_CodeSniffer standard — composer require --dev joomla/coding-standards, point phpcs --standard=Joomla at the source tree, and gate the pipeline on it. It is dev-only, so it never ships to production. The cost is not integration; it is the steady drip of fixing sniffs that no longer match current PHPCS releases. If we adopt, we own that.

Risk statement: low technical risk, non-trivial maintenance risk, and a licensing question worth one email to legal. The strategic risk is the real one — adopting a sunset ruleset signals the wrong thing about our engineering standards, and that is the outcome I would most want to avoid.