Php Code Sniffer Standard Laravel Package

Getting Started

Reality check first: this package is archived and effectively a single-team coding standard (Isaac Eindhoven's internal PHPCS ruleset). With ~10 stars and zero dependents there is no upstream maintenance, no issue triage, and no PHP-version tracking. Treat it as a source of rules you can read and copy, and only install it directly if you're auditing an existing project that already depends on it, or your team has explicitly decided to mirror Isaac's conventions. For anything new, prefer PSR-12 + Laravel Pint or Slevomat.

If you do install it (existing project or audit):

composer require --dev isaac/php-code-sniffer-standard

Check what PHPCS version it drags in — the archived ruleset was written against an older squizlabs/php_codesniffer and may pin something you don't want.

Where to look first, in this order:

1. composer.json — confirms type, the required PHPCS version, and any extra.phpcodesniffer.installed_paths config. That installed_paths entry is what lets --standard=Isaac resolve by name.
2. The ruleset XML (typically Isaac/ruleset.xml or src/ruleset.xml — verify the path in the repo). This is the actual product; everything else is packaging.
3. Sniffs/ — any custom sniffs, which are where the real opinions live. If there are none, this is a thin wrapper around PSR-12 plus a handful of slevomat rules.

First use case — run it against one file to see what it actually enforces before wiring anything into CI:

vendor/bin/phpcs --standard=vendor/isaac/php-code-sniffer-standard/Isaac \
    --report=full -s app/Http/Controllers/UserController.php

The -s flag prints sniff codes (Isaac.Naming.Foo.Bar, SlevomatCodingStandard...). Those codes are what you'll reference in excludes and in your own ruleset, so get comfortable with -s immediately.

Then dry-run the auto-fixer on a throwaway branch:

vendor/bin/phpcbf --standard=vendor/isaac/php-code-sniffer-standard/Isaac app/
git diff

If the diff is enormous, that tells you what you're signing up for before you commit to the standard.

Implementation Patterns

Keep one source of truth in phpcs.xml. Don't scatter --standard= flags across Composer scripts and CI. Put a project-level ruleset at the repo root that references the vendor standard, so you can later swap the referenced ruleset for a forked one without touching CI:

<?xml version="1.0"?>
<ruleset name="project">
    <description>Project coding standard</description>

    <file>app</file>
    <file>config</file>
    <file>database</file>
    <file>routes</file>
    <file>tests</file>

    <arg name="extensions" value="php"/>
    <arg name="colors"/>
    <arg value="p"/>

    <!-- Reference the vendor standard, then apply project-specific exclusions -->
    <rule ref="vendor/isaac/php-code-sniffer-standard/Isaac"/>

    <!-- Known false positives; document *why* next to each -->
    <rule ref="SlevomatCodingStandard.Functions.StrictCall">
        <exclude-pattern>tests/*</exclude-pattern>
    </rule>
</ruleset>

Then vendor/bin/phpcs with no arguments picks it up automatically. This is the pattern that lets you extract later.

Composer scripts — split lint from fix. Developers want one command to run and one to fix, and CI wants a non-fixing command that fails the build:

"scripts": {
    "lint": "phpcs --report=full",
    "lint:fix": "phpcbf || true",
    "lint:changed": "phpcs --report=full $(git diff --name-only --diff-filter=ACMR origin/main... | grep '\\.php$' | tr '\\n' ' ')"
}

The lint:changed variant is the highest-leverage pattern for legacy codebases — pre-commit hooks and fast local checks run only against files a developer touched, so the archived standard's false positives don't block work outside the current diff.

Baseline for existing code. If you're adopting on top of a messy codebase, generate a PHPCS baseline so only new code must comply:

vendor/bin/phpcs --report=full --report-file=phpcs-baseline.txt

Then suppress the baseline's files in your phpcs.xml (or use a baseline plugin/--ignore patterns depending on your PHPCS version). Commit the baseline, ratchet it down over time. This is the difference between adopting the standard and rewriting the codebase.

CI wiring. A dedicated lint stage that fails on violations, pinned to the same PHP and PHPCS versions as local dev:

- run: composer install --no-interaction
- run: composer lint

Parallelize by path (phpcs app/ config/ database/ routes/) if the repo is large; PHPCS scales linearly and each invocation is independent.

Fork-and-vendor pattern (recommended for anything long-lived). Because the upstream is archived, the sustainable move is to copy the ruleset.xml (and any Sniffs/ you care about) into an internal tools/phpcs/ directory or an internal composer package under MIT, and point phpcs.xml at that instead of vendor/isaac/.... You keep the rules, own the maintenance, and stop the archived status from being a risk on your dependency graph. From a developer's perspective nothing changes in day-to-day workflow — composer lint still does the same thing — but you can now patch sniffs when PHP or PHPCS moves.

IDE integration. PHPCS support in PhpStorm / VS Code reads from phpcs.xml. Point the plugin at vendor/bin/phpcs and let it show sniff codes inline. Developers then see violations as they type rather than after a CI round-trip — this alone cuts style-review comments substantially.

Gotchas and Tips

It's archived — every bug is yours. No PHP 8.x / PHPCS 4.x compatibility work will ever land upstream. Pin squizlabs/php_codesniffer (and slevomat/coding-standard if required) to exact versions in your composer.json, and treat any upgrade as a deliberate, tested migration. A floating ^3.0 range will one day produce failures across every repo at once.

It collides with Laravel Pint. Pint (a PHP-CS-Fixer wrapper) is Laravel's first-party formatter, and it will fight this standard over spacing and formatting — running both produces non-deterministic diffs as each tool flips the other's changes. Decide one formatter owner. The pragmatic split: let Pint own formatting, and scope PHPCS to non-formatting sniffs (naming, strict types, complexity, dead code) via a hand-picked ruleset. Never run pint and phpcbf in the same pipeline on the same files.

--standard= by name fails silently until installed_paths is set. That's the extra.phpcodesniffer.installed_paths entry in composer.json — when Composer's plugin system is disabled (allow-plugins in Composer 2.2+), that registration never happens and --standard=Isaac complains the standard doesn't exist. Either allow the plugin or reference the ruleset by full path (--standard=vendor/isaac/.../Isaac), which is more robust and what you should default to anyway.

False positives on idiomatic Laravel. Facades, magic methods, collection chains, and Laravel's macro-heavy code confuse older sniffs — expect SlevomatCodingStandard.Functions.StrictCall-style complaints on code that's correct. The fix is a documented exclusion in phpcs.xml with a comment explaining why, applied via exclude-pattern. Without a fast suppression path and a clear owner, developers start disabling rules globally or ignoring the tool entirely.

phpcbf needs a clean working tree. Always run the auto-fixer on a branch with committed or stashed changes, then git diff — it rewrites files in place and it's easy to lose uncommitted work in a mass-fix pass. Even better: run phpcbf per-directory for large reformats so you can review and commit changes in reviewable chunks.

Sniff codes are stable identifiers — use them. When excluding or configuring a rule, reference the sniff code (Isaac.Naming.Foo.Bar) rather than a message string. Codes survive PHPCS upgrades; messages don't. phpcs -s --report=full is your discovery mechanism — keep it in muscle memory.

Reports don't run in parallel mode by default. For large repos, PHPCS's own parallelism (--parallel=8) or splitting the command by directory is what keeps CI under a reasonable runtime. Do this only after baselining, or you'll parallelize a wall of failures.

Version rot is the real failure mode, not today's bugs. Pin PHPCS in CI to the same version local dev uses; write down the PHP support matrix in your phpcs.xml or a README. When the ruleset stops installing on the next PHP minor, you want a documented path to patch the vendored copy — not a fire drill across every repo. This is the single strongest argument for the fork-and-vendor pattern over depending directly on isaac/php-code-sniffer-standard: same day-to-day developer experience (composer lint), but you own the upgrade.