Php Standard Laravel Package

Getting Started

tenantcloud/php-standard is a dev-only coding-standard package — treat it as tooling, not runtime code. Nothing it ships belongs in production, so it goes in require-dev and its config normally lives at the repo root next to composer.json.

Minimal steps

1. Install as a dev dependency and let Composer resolve the toolchain:

   composer require --dev tenantcloud/php-standard
   

2. Check what the release actually pins. This is the first thing to look at after v2.3.0, because a standards package is mostly a wrapper around php-cs-fixer (and possibly Rector/PHPStan):

   composer show tenantcloud/php-standard
   composer show --tree tenantcloud/php-standard
   

   If the package declares laravel/framework or illuminate/* constraints, confirm they now allow ^12.0 — that is the entire substance of the v2.3.0 change. If it does not depend on the framework directly, the release is effectively a "tested against Laravel 12 / bumped dev deps" signal and should be a drop-in.

3. Wire up the config. The package ships a ruleset you reference from your own fixer config rather than editing in vendor/. Look in vendor/tenantcloud/php-standard/ for the entry point (typically a config factory or a .php-cs-fixer.dist.php / ruleset array) and read it before adopting — you want to know whether it returns a Config object or a rules array, since that determines how you compose it.

4. First use case: run it read-only on an existing codebase before letting it write anything.

   vendor/bin/php-cs-fixer fix --dry-run --diff
   

   Then commit a formatting-only pass as its own PR, with git blame-ignore configured so the churn doesn't poison history.

Implementation Patterns

Root config that extends the package. Keep your own .php-cs-fixer.dist.php thin so upgrades don't require merging upstream edits:

<?php
// .php-cs-fixer.dist.php
$config = require __DIR__.'/vendor/tenantcloud/php-standard/config.php'; // verify actual path

return $config
    ->setFinder(
        PhpCsFixer\Finder::create()
            ->in([__DIR__.'/app', __DIR__.'/tests', __DIR__.'/database'])
            ->notPath(['bootstrap/cache', 'storage'])
    );

If the package returns a rules array instead, use ->setRules(array_merge($standardRules, [...project overrides...])). Either way, project-specific deviations live in your file, never in vendor/.

Composer scripts as the interface. Developers should not memorise tool flags:

"scripts": {
    "cs": "php-cs-fixer fix",
    "cs:check": "php-cs-fixer fix --dry-run --diff",
    "test": ["@cs:check", "@php artisan test"]
}

cs for local autofix, cs:check in CI so the pipeline fails instead of silently rewriting.

Adoption on a brownfield app. Do the initial fix on a dedicated branch with no other changes, add the resulting commit hash to .git-blame-ignore-revs, and only then add cs:check to CI. Mixing a formatting sweep into a feature branch makes review impossible and conflicts certain.

IDE and editor integration. Point PHPStorm's "PHP CS Fixer" inspection at the same config file so on-save formatting and CI agree. Any drift here is the number one source of "my branch fails CI for no reason" tickets.

Pre-commit hook, scoped. Run the fixer only on changed files rather than the whole tree, otherwise the hook takes long enough that people --no-verify it:

vendor/bin/php-cs-fixer fix $(git diff --cached --name-only --diff-filter=ACM | grep '\.php$')

Laravel 12 upgrade path. When bumping the app to Laravel 12, upgrade this package in the same PR (composer require --dev tenantcloud/php-standard:^2.3), then run cs:check. If the only diff is the coding standard bump, the upgrade is clean; a large unexpected diff usually means transitive tool versions moved.

Gotchas and Tips

• It's a dev dependency — never require. Adding it to require drags the standard and its transitive tooling into your production image and into composer audit noise. Check composer.json after install; some packages' READMEs show the wrong section.
• Lockfile, not version range, is truth. Standards packages frequently allow wide ranges on php-cs-fixer. Two developers can resolve different fixer patch versions and get different output. Pin with composer update --dev tenantcloud/php-standard --with-dependencies in a dedicated commit, and let CI use composer install from the lockfile.
• v2.3.0 is a minor bump. Under semver, expect no rule removals. But if the release also widened framework constraints, a composer update can pull a newer php-cs-fixer that does change output. Read composer.lock in the bump PR, not just the changelog.
• Empty diff after upgrading to Laravel 12 is a pass, not a red flag. If the package only declares framework support, no code changes are expected. Verify by running the suite on Laravel 12 rather than looking for a changelog entry describing behaviour.
• --dry-run --diff in CI, plain fix locally. If CI runs the fixer in write mode, you get a green build and uncommitted changes on the runner — the failure disappears and formatting debt accumulates.
• Watch excluded paths. bootstrap/cache, storage, generated migrations from packages, and _ide_helper.php should all be excluded; the finder in your config is where you enforce that, not the package.
• Don't hand-edit files in vendor/. If a rule is wrong for your project, override it in your root config and open an upstream issue. Edits under vendor/ vanish on the next composer install, and there's no lockfile record of them.
• Extension points to look for before assuming you're stuck: a published ruleset file (vendor:publish), a config factory accepting overrides, or a documented rules array you can array_merge — check the README and the package's src/ since these are rarely all documented.
• PHP version coupling. The fixer version resolved by the package dictates the minimum PHP your dev tooling needs, which can be newer than your production PHP. Verify your CI image's PHP version satisfies the dev toolchain, otherwise cs:check fails on the runner while passing locally.
• Debugging a surprising fix: vendor/bin/php-cs-fixer fix path/to/File.php -vvv shows exactly which rule rewrote what; describe on a rule name confirms what it actually enforces if the name is misleading.