Php Code Style Laravel Package

Getting Started

This package is a shareable code-style configuration set (PHP_CodeSniffer ruleset, PHP-CS-Fixer config, and .editorconfig) rather than a runtime library. It installs nothing into your app; you point your tools at the files it ships.

1. Pull it into dev dependencies only:

   composer require --dev longman/php-code-style
   

2. Inspect what you actually got — this is the critical first step, since the layout is not documented well:

   ls -R vendor/longman/php-code-style
   

   Expect a ruleset XML (e.g. phpcs.xml), a fixer config (.php_cs / .php_cs.dist), and editor defaults. Note the exact ruleset name before referencing it anywhere.
3. Smoke-test it directly, without touching your project config:

   vendor/bin/phpcs --standard=vendor/longman/php-code-style/phpcs.xml src
   

4. Once the output looks sane, vendor the config into your own root-level phpcs.xml.dist / .php_cs.dist (see below) so your rules survive an upstream bump.

First real use case: a legacy project where you want a single, consistent standard enforced in CI. Run the ruleset ad hoc on one directory, triage the noise, then codify the final ruleset in your repo.

⚠️ Check the PHP/PHPCS compatibility before committing to it — see Gotchas. The last release is 2017-06-16.

Implementation Patterns

Wrap, don't reference directly. The most robust pattern is a thin root config that extends the package's ruleset and adds project-specific exclusions:

<!-- phpcs.xml.dist -->
<?xml version="1.0"?>
<ruleset name="Project">
    <rule ref="vendor/longman/php-code-style/phpcs.xml"/>
    <file>src</file>
    <file>tests</file>
    <exclude-pattern>*/migrations/*</exclude-pattern>
    <rule ref="Generic.Files.LineLength">
        <properties><property name="lineLimit" value="120"/></properties>
    </rule>
</ruleset>

This keeps a single source of truth while letting you dial severity per-sniff. Prefer phpcs.xml.dist so developers can keep a local phpcs.xml override out of git.

Wire it into composer scripts so nobody has to remember flags:

"scripts": {
  "cs": ["phpcs"],
  "cs:fix": ["phpcbf", "php-cs-fixer fix"]
},
"scripts-descriptions": { "cs": "Report style violations" }

phpcs with no arguments auto-discovers phpcs.xml.dist in the working directory — that's why the wrapper file matters more than the --standard path.

PHP-CS-Fixer: copy, don't include. Fixer configs are executable PHP returning a Config object; loading a vendor config and mutating it is brittle across fixer majors. Copy the rule array into your own config, then apply project overrides:

// .php-cs-fixer.dist.php
$config = (new PhpCsFixer\Config())
    ->setRiskyAllowed(false)
    ->setRules([ /* transcribed from vendor .php_cs */ ]);
$finder = PhpCsFixer\Finder::create()->in(__DIR__.'/src');
return $config->setFinder($finder);

CI pattern: run the reporter in the pipeline, the fixer locally/pre-commit.

• CI: vendor/bin/phpcs --report=checkstyle --report-file=build/phpcs.xml -q
• Local: vendor/bin/phpcbf on save, or a git pre-commit hook (CaptainHook / GrumPHP) invoking composer cs.
• IDE: import the XML ruleset into PhpStorm's Code Style so the formatter and the linter agree, and let .editorconfig handle whitespace/indent for non-PHP files.

Two-tier rollout for existing codebases: apply the standard to new directories immediately (<file>src/NewModule</file>) and use --sniffs to enforce only high-value sniffs (naming, unused imports) on legacy code until it's cleaned up.

Gotchas and Tips

• Age is the biggest risk. A 2017 ruleset was authored against PHP_CodeSniffer 2.x and/or early 3.x, and PHP-CS-Fixer 1.x/2.x. Sniff names, defaults, and config-file conventions have all shifted since (PHPCS 3.x sniff renames; PHP-CS-Fixer 3.x dropping .php_cs in favour of .php-cs-fixer.php). Pin both tools in require-dev to versions the ruleset actually works with, and verify the fixer config is even read by your installed major.
• vendor/ in a ruleset path is fragile. Relative <rule ref="vendor/..."> breaks when phpcs runs from a subdirectory. Use __DIR__-style absolute paths, or run phpcs from the project root only. In CI, invoke it from the repo root explicitly.
• Don't ship to production. require-dev + composer install --no-dev in the build image. If a composer.lock includes it, that's fine — just confirm autoload isn't relying on it.
• Silencing a sniff without forking: <rule ref="..."><severity>0</severity></rule> disables; <exclude name="..."/> on an inline phpcs:ignore comment scopes it to one line. Prefer exclusion at the ruleset level over sprinkling comments.
• Caching lies. phpcs --cache and php-cs-fixer's cache will happily report stale results after you edit the ruleset. Delete the cache file (.phpcs-cache, .php_cs.cache) whenever rules change, or skip caching in CI.
• Line-length mismatches are the classic friction point: .editorconfig max_line_length, the PHPCS LineLength sniff, and the fixer's line-length rules each have their own default. Reconcile them in one place or you'll get fix → lint → fix loops.
• Debug visibility: run vendor/bin/phpcs -s to see sniff codes in the report (essential when you need to exclude something), and -e to list every registered standard. phpcs -i confirms whether the package registered a named standard or is just a raw XML file.
• Extension point: if you need to change behavior permanently, fork the repo, adjust the ruleset, and require your fork by VCS path ("repositories": [{"type": "vcs", "url": "..."}]) — with 9 stars and zero dependents, upstream responsiveness is not something to plan around.
• Verify before adopting: confirm the package is not a Composer plugin or installer (i.e., it does not copy files into your tree). If it is, check what it writes and make sure those artifacts are gitignored or committed deliberately.