Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Coding Standard Laravel Package

eve/coding-standard

Eve Coding Standard provides a ready-made PHP_CodeSniffer ruleset for enforcing consistent, Laravel-friendly coding style across PHP projects. Install it to standardize formatting, catch style issues early, and simplify CI checks.

View on GitHub
Deep Wiki
Context7

Getting Started

eve/coding-standard is a PHP_CodeSniffer-based ruleset that encodes Eve's house style for Laravel projects. It is a thin distribution package — it pulls in squizlabs/php_codesniffer plus supporting sniffs and ships an Eve ruleset you reference from a local phpcs.xml. There is no service provider, no config publish, no runtime dependency; it is purely a dev tool.

Minimal setup:

composer require --dev eve/coding-standard

Then create phpcs.xml.dist at the project root:

<?xml version="1.0"?>
<ruleset name="Project">
    <file>app</file>
    <file>config</file>
    <file>database</file>
    <file>routes</file>
    <file>tests</file>

    <rule ref="Eve"/>

    <exclude-pattern>*/migrations/*</exclude-pattern>
    <exclude-pattern>*/vendor/*</exclude-pattern>
</ruleset>

Run the standard against a single file first to see what it actually flags before wiring it into CI:

vendor/bin/phpcs app/Http/Controllers/UserController.php -s

The -s flag prints the sniff source, which is the fastest way to learn which of Eve's rules you are tripping and whether the fix is auto-fixable. First realistic use case: run phpcbf (the fixer) over app/ on a greenfield branch and commit the result as an isolated "apply coding standard" PR, so all subsequent diffs are behavioral rather than stylistic.

Implementation Patterns

Composer scripts as the entry point. Expose lint and fix as script aliases so nobody has to remember paths or flags:

"scripts": {
    "lint": "phpcs",
    "lint:fix": "phpcbf"
}

composer lint in CI, composer lint:fix locally before pushing. This is the single most valuable pattern — developers run the same command the pipeline runs.

CI integration. Because it's PHPCS, output formats are built in. Use --report=checkstyle or --report=full and let your CI annotate. A GitHub Actions step is just:

- run: composer lint -- --report=checkstyle

Fail the build on violations, but keep the fix step off in CI. Never auto-commit fixes from a pipeline.

Editor + pre-commit wiring. Point PHPStorm's "Code Sniffer" inspection at vendor/bin/phpcs and set the standard to the project phpcs.xml. For VS Code, phpcs via shevaua.phpcs. Pair it with a pre-commit hook (captainhook, husky + lint-staged, or a plain .git/hooks/pre-commit calling vendor/bin/phpcs --filter=gitstaged style wrapper) so violations never reach the branch. This is where the standard earns its keep — enforcement at the developer's fingertips rather than in review comments.

Scoping to Laravel conventions. Eve's ruleset assumes Laravel idioms, so scope it to app/, routes/, database/factories, database/seeders, and tests/. Exclude bootstrap/cache, storage, public, and migrations — migrations are generated and frequently hand-tweaked, and rewriting them creates noise without value. Config files can be included but you'll likely want to suppress certain multi-line array rules there.

Incremental adoption on legacy code. Don't fix the world on day one. Either use a path-scoped phpcs.xml per directory (run strict on new modules, loose on legacy), or generate a PHPCS baseline via a third-party baseline tool and only fail on regressions. A "grandfather file list" in the ruleset (<exclude-pattern>) is pragmatic for a first pass.

Pair with a formatter, don't fight it. If the team also uses Pint, decide which is authoritative on formatting. Pint and a PHPCS ruleset will conflict on array alignment, operator spacing, and import ordering. The clean split: PHPCS (Eve) owns structural and sniff-style rules, Pint owns pure formatting, or you drop one entirely. Running both in CI with overlapping rules produces unfixable flip-flops.

Gotchas and Tips

It is stale — verify PHP and PHPCS compatibility before adopting. Last release was April 2021. That predates PHP 8.1 enums, readonly properties, and first-class callable syntax, and it targets an older squizlabs/php_codesniffer / slevomat/coding-standard line. On PHP 8.2+ you will likely hit deprecation notices from transitive sniffs or, worse, parse errors on newer syntax. Pin your PHPCS version explicitly and test on your actual PHP target before rolling out. If it breaks, you're maintaining a fork.

Conflicting transitive sniff versions. Because it bundles sniff libraries, composer update on other dev dependencies can bump a shared sniff package and silently change rule behavior. Lock the sniff dependency versions in composer.json (slevomat/coding-standard, if present, is the usual suspect) rather than trusting the standard's own constraint.

Autofix is not total. phpcbf handles whitespace, ordering, and many docblock rules, but anything involving semantics (unused imports across conditional code, type declarations, complexity sniffs) requires manual work. Budget review time for phpcbf output — it occasionally mangles multi-line closures and heredocs. Always run the fixer on a clean working tree so you can git diff and revert individual hunks.

Ruleset ref name. Confirm the exact <rule ref="..."/> value by inspecting vendor/eve/coding-standard/ — the ruleset XML filename defines the ref. If Eve doesn't resolve, run vendor/bin/phpcs -i to list installed standards and use the printed name.

Zero dependents means zero community signal. With 7 stars and no dependents, debugging is entirely on you. The fastest path when a rule misfires is phpcs -s to get the sniff code, then <rule ref="Eve.Sniffs.Category.Rule"><severity>0</severity></rule> to mute it locally rather than forking. Keep a running list of muted sniffs in phpcs.xml.dist with a comment explaining why — this doubles as an ADR for your team's style deviations.

Extension point is the ruleset, not the code. Customization is XML-only: severity overrides, exclude patterns, and per-sniff property configuration. There's no plugin API. If you need a genuinely new rule, add your own sniff directory and reference it alongside Eve, or switch to a maintained standard (doctrine/coding-standard, slevomat/coding-standard directly, or Laravel Pint) and port Eve's house rules on top. Given the age, that migration is worth planning for rather than deferring.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode
jjsquady/round-robin
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route