Php Styles Laravel Package

Getting Started

This is a codestyle distro, not a runtime library. It ships Coding Labs' opinionated ruleset (most likely a PHP-CS-Fixer config, a PHP_CodeSniffer ruleset.xml, or both) so that every repo in the org formats code identically without copy-pasting rule arrays. Nothing it does is reachable from application code — the deliverable is a config you point a tool at.

Minimal steps:

composer require --dev codinglabsau/php-styles

Because the package is archived at 1 star with zero dependents, inspect the layout before writing any config — this is the single most important first step:

ls -R vendor/codinglabsau/php-styles
cat vendor/codinglabsau/php-styles/composer.json   # what it requires, what it ships

You are looking for one of three shapes:

1. A PHP-CS-Fixer config file — typically src/config.php, .php-cs-fixer.php, or config/rules.php returning a PhpCsFixer\Config.
2. A PHPCS ruleset — ruleset.xml at the package root, referenced by name.
3. A rules array / class — e.g. CodingLabs\Styles\Rules::default().

For shape (1), .php-cs-fixer.dist.php in your repo becomes a thin wrapper:

<?php
$config = require __DIR__.'/vendor/codinglabsau/php-styles/src/config.php';

return $config->setFinder(
    PhpCsFixer\Finder::create()
        ->in(__DIR__)
        ->exclude(['vendor', 'storage', 'bootstrap/cache'])
);

For shape (2), a one-line phpcs.xml.dist:

<ruleset name="Project">
    <rule ref="./vendor/codinglabsau/php-styles/ruleset.xml"/>
    <file>app</file>
    <file>tests</file>
</ruleset>

First use case: run it in dry-run against a single small directory before touching the whole codebase.

vendor/bin/php-cs-fixer fix app/Console --dry-run --diff -vvv
# or
vendor/bin/phpcs app/Console

Read the diff output. That output is the package's value proposition — it tells you immediately whether the Coding Labs style matches your existing conventions or will fight them.

Implementation Patterns

Pin the version, always. Archived projects don't get rule additions, but they also don't get compatibility fixes. Use an exact constraint ("codinglabsau/php-styles": "1.2.0") rather than ^1.0, and commit composer.lock.

Composer scripts as the day-to-day interface. Developers should never memorize the binary invocation:

"scripts": {
    "cs": "php-cs-fixer fix",
    "cs:check": "php-cs-fixer fix --dry-run --diff",
    "cs:changed": "php-cs-fixer fix $(git diff --name-only --diff-filter=ACMR origin/main... | grep '\\.php$' | tr '\\n' ' ')"
}

cs:changed matters: the full-codebase run is slow and noisy on mature repos, while a changed-files run is fast enough to sit in a pre-commit hook.

Land the initial reformat as one isolated commit. On first adoption the diff will be enormous. Do it in a commit that touches nothing else, then record the SHA in .git-blame-ignore-revs so git blame stays readable. Reviewers approve it unread; a mixed commit is unreviewable.

CI as the enforcement point, local fix as the workflow. CI must only check, never fix:

- run: composer install --prefer-dist --no-interaction
- run: composer cs:check

If CI auto-fixed and pushed, you'd get silent style commits on feature branches and merge conflicts on every open PR.

Override surgically, don't fork the ruleset. Whatever the package returns is a mutable object or array — adjust the two or three rules your team disagrees with at the wrapper level:

$config->setRules(array_merge(
    $config->getRules(),
    ['strict_comparison' => false]
));

Keep a comment explaining why for each override. Every override silently forks you from the standard, and the next repo will copy it forward.

Handle the PHPCS standard-path case. If the package ships a ruleset for phpcs, PHPCS does not autoload it from vendor/. Register it once per machine/project:

vendor/bin/phpcs --config-set installed_paths vendor/codinglabsau/php-styles

Better: rely on the local phpcs.xml.dist <rule ref="./vendor/..."> path form, since the --config-set state lives outside the repo and will not exist on a fresh CI runner.

Adoption order for multi-repo orgs. Start with a greenfield or small service, not the monolith. Confirm the ruleset's PHP version assumption (trailing commas, arrow functions, constructor promotion) against your oldest supported runtime before rolling out.

Gotchas and Tips

Archived means frozen — treat this as a snapshot, not a dependency you can lean on. No CVE responses, no new PHP 8.x rule support, no fixes when a bundled php-cs-fixer constraint drifts out of range. composer require may pull a second copy of php-cs-fixer into vendor/codinglabsau/php-styles/vendor/ if its constraint conflicts with yours. Check with composer why php-cs-fixer and, if there's a conflict, either align your constraint downward or don't install its tooling dependency at all.

Version-couple the fixes to your fixer. PHP-CS-Fixer renames and removes rules across majors (@PSR2 → @PSR12, dozens of renames in v3). A ruleset written for v2 will throw Unknown rule errors under v3. The error message names the offending rule — that's your map for adding overrides.

--dev is load-bearing. Anyone running composer install --no-dev (production images, some CI stages) won't have the package. Keep style steps in a job that installs dev dependencies; don't try to run style checks from a production container.

Gitignore .php-cs-fixer.cache. The cache is machine- and path-specific; committing it produces spurious diffs and stale-rule confusion when someone bumps the package.

Two tools, two truths. If you already run Pint or PHPCS, adding this package means two formatters with overlapping opinions fighting over the same files — visible as re-modified files after each save. Pick one. If the package is PHPCS-based and you use Pint (a PHP-CS-Fixer wrapper), you're maintaining contradictory configs for the same rules and should convert one to the other.

IDE integration causes ghost conflicts. A developer with "format on save" using their personal PHP-CS-Fixer profile will produce diffs that survive composer cs. Point the IDE at the project's .php-cs-fixer.dist.php explicitly; don't assume it picks it up.

Debugging a rule you can't identify: vendor/bin/php-cs-fixer fix path --diff -vvv attributes each change to the rule that made it. Use vendor/bin/php-cs-fixer describe <rule> for the rationale, and --rules to dump the fully resolved merged set — that's the fastest way to see what the package actually applied versus what you thought it applied.

Extension points are just the config object. Because PHP-CS-Fixer configs are plain PHP objects, the supported way to diverge is setRules()/getRules() on the returned config (or a copied rules XML). Editing files inside vendor/ is the common mistake — it vanishes on the next composer install and silently reverts your team's decisions.

If you outlive it, vendor it. Given zero dependents and an archived status, the pragmatic long-term move is to copy the resolved ruleset into your own .php-cs-fixer.dist.php (or a private your-org/php-styles fork under your namespace) so you control PHP version support and can accept upstream-style changes on your own schedule.