Product Decisions This Supports
- Feature-level: standardizing code style before it becomes a debate. A shared PHPCS ruleset turns "tabs vs. spaces / where do the braces go / how strict are type hints" into a CI gate rather than a recurring code-review argument. This package is a ready-made opinionated Laravel-flavored baseline, so you can decide whether to enforce a standard without spending engineering time authoring one from scratch.
- Roadmap: technical-debt and onboarding investment. A machine-checkable standard is a prerequisite for scaling a Laravel codebase across multiple squads or contractors — it shortens review cycles and makes "does this look like our code?" objective. This is a decision about when you invest in that layer, not a feature in itself.
- Build vs. buy vs. fork: the real decision here. Given 7 stars, 0 dependents, and a last release of April 2021, "buy" is the wrong frame. The realistic options are (a) adopt as an unmodified dev dependency, (b) fork it and treat the XML/ruleset as in-house configuration you own, or (c) skip it and use Laravel Pint / PHP-CS-Fixer or
slevomat/coding-standard. For most teams the PM-level call is (b) or (c); (a) is only defensible if you are already inside the Eveio ecosystem.
- Use cases it serves: greenfield Laravel services establishing a style baseline on day one; legacy repos wanting an incremental
phpcs ratchet on changed files only; monorepos wanting one shared ruleset package consumed by several apps; pre-Pint projects still standardized on PHP_CodeSniffer.
- Use cases it does not serve: automated refactoring/fixing (a ruleset detects, it doesn't rewrite), static analysis or type-safety enforcement (that's PHPStan/Larastan territory), or anything requiring PHP 8.1+ and current Laravel support guarantees.
- Opportunity read (5.5/10): the problem — codified style consistency in Laravel teams — is a real, recurring, low-cost-to-solve need with clear value. The package is weak: low adoption means no external bug-finding, no community pressure to keep up with new PHP syntax, and a single-maintainer bus factor. So the opportunity is in the problem space, and you should capture it with a maintained ruleset, using this repo as reference material rather than as a dependency.
When to Consider This Package
Consider it when all of the following hold:
- Your team is on PHP_CodeSniffer (not Pint/PHP-CS-Fixer) and intends to stay there, because migrating toolchains costs more than the ruleset saves.
- You want an opinionated Laravel-shaped baseline quickly and are willing to vendor or fork the ruleset into your own repo, pinning the exact version and owning future updates.
- Your PHP and Laravel versions are within what a 2021-era ruleset can parse — verify this explicitly against your target runtime before committing; stale sniffs and PHP_CodeSniffer major-version constraints are the most likely breakage.
- You have a named owner for the ruleset. A standard nobody maintains silently rots into false positives and gets disabled.
Look elsewhere when:
- You are on modern Laravel (9+) and PHP 8.x. Laravel Pint is the default-path answer: first-party, zero-config, actively maintained, and already familiar to new hires. Choosing this package over Pint needs a specific justification.
- You need fixing, not just reporting. Pint and PHP-CS-Fixer rewrite code; a PHPCS standard does not.
- You need guarantees. Zero dependents and a 2021 last release mean no compatibility promise, no CVE responsiveness, and no signal that anyone else has run this against your stack. Do not put it on the critical path of a release pipeline without a fork.
- Your org already has a style standard (PSR-12 plus internal conventions). Layering a third-party opinion on top creates conflicting rules and noisy diffs.
- The decision is really about static analysis. Don't let a style ruleset get scoped as "code quality"; that conversation belongs to PHPStan/Larastan and is a separate budget line.
How to Pitch It (Stakeholders)
For executives (one paragraph): We have a recurring, low-grade tax on engineering time — every pull request renegotiates formatting, and reviewers spend attention on style instead of logic. The fix is a codified, automated style check in CI. This specific package is a pre-built Laravel-oriented ruleset that could give us a starting point for free, but it is a small, unmaintained open-source project (7 stars, no downstream users, last updated 2021), so I do not recommend taking a direct dependency on it. My recommendation is to adopt the category — most likely Laravel Pint, which is first-party and free — and treat this repo as reference material if we need a custom ruleset. Cost is effectively engineering time only; the payoff is shorter review cycles and faster onboarding, and the risk of the recommended path is near zero.
For engineering (the honest version): This is a PHP_CodeSniffer standard — a ruleset, not a tool. It encodes Eve's Laravel conventions and can be wired into phpcs.xml and CI in under an hour. Three caveats before anyone runs composer require: it hasn't shipped since April 2021, it has no dependents to validate it against current PHP 8.x syntax, and PHP_CodeSniffer's own major-version drift may make it painful to install. If we want it, we fork it, pin it, own it, and add a ticket to review it quarterly. Otherwise we use Pint, which fixes code rather than just complaining about it, and get 90% of the value with none of the maintenance. Either way, the actual deliverable is the same: a CI gate that fails the build on style, so humans stop reviewing it.