Coding Standard Laravel Package

Getting Started

• Install as a dev dependency: composer require --dev chadicus/coding-standard.
• Verify PHPCS sees the standard: vendor/bin/phpcs -i. The package registers a standard (commonly referenced in rulesets as Chadicus; confirm the exact name from phpcs -i).
• Add a root phpcs.xml and start with a narrow scope:

  <?xml version="1.0"?>
  <ruleset name="Laravel App">
      <description>Project coding standard</description>
      <file>app</file>
      <file>tests</file>
      <arg name="extensions" value="php"/>
      <arg name="colors"/>
      <rule ref="Chadicus"/>
  </ruleset>
  

• First use case: run vendor/bin/phpcs on app/ only to establish a baseline. Fix automatically with vendor/bin/phpcbf, then review the diff before widening scope to tests/ and other directories.
• If the standard name is not found, run composer dump-autoload and re-check phpcs -i; PHPCS 3.6+ auto-discovers standards installed via Composer.

Implementation Patterns

• Composer scripts for day-to-day use:

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

  Then composer lint locally and in CI.
• CI integration (GitHub Actions example):

  - run: composer install --no-interaction --prefer-dist
  - run: vendor/bin/phpcs --report=checkstyle --report-file=phpcs.xml
  

  Use --report=summary for human-readable CI logs and --report=checkstyle for annotations.
• IDE integration: In PhpStorm, point Code Sniffer to vendor/bin/phpcs and set the standard path to vendor/chadicus/coding-standard (or the registered standard name). Enable “Show sniff name” so failures map to actionable rules.
• Directory-specific rulesets: include the package standard globally, then relax or tighten per path:

  <rule ref="Chadicus"/>
  <rule ref="Chadicus">
      <exclude name="Some.Sniff.Code"/>
  </rule>
  

• Laravel Pint coexistence: Pint is PHP-CS-Fixer-based, this package is PHPCS-based. Pick one as the source of truth for formatting, or run Pint first and PHPCS second on a clean tree to avoid formatter tug-of-war. Many teams use PHPCS for sniff-level correctness and Pint for style.
• Exclude generated and framework paths explicitly: bootstrap/cache, storage, vendor, and any generated migration or IDE helper files.
• Incremental adoption: Use --ignore=* plus explicit <file> entries, or maintain a baseline via --report=summary and fail CI only on new violations in the changed-file set.

Gotchas and Tips

• v2.0.1 is a patch fix for the absoluteNestingLevel property name. If your custom ruleset or sniff configuration referenced that property (especially with the old/incorrect spelling), re-check it after upgrading. A property that was previously ignored may now take effect and surface new violations. Run vendor/bin/phpcs across the codebase after the bump and review the diff rather than assuming a patch release is behavior-neutral.
• Config property names are exact and case-sensitive. A misspelled property can silently do nothing. Confirm properties are recognized with vendor/bin/phpcs -e (lists sniffs) and -s (shows sniff codes in reports).
• Caching: PHPCS can cache results; if rule changes do not appear, clear the cache file or run with a fresh --cache path.
• Standard discovery: “Standard not found” usually means Composer autoload or installed_paths is stale. composer dump-autoload and phpcs -i are the first debugging steps.
• phpcbf safety: Always run auto-fixers on a clean Git working tree. Review phpcbf output before committing; some sniffs make non-trivial structural changes.
• PHP version compatibility: Pin PHPCS and this package versions to match your Laravel/PHP matrix (Laravel 10/11 require PHP 8.1+). Test upgrades in CI before merging.
• Extension points: Wrap the package standard in your own ruleset and add custom sniffs or exclusions there rather than editing vendor files. Use <exclude-pattern> for generated code and <rule ref="..."><properties> for per-project sniff tuning.
• Debugging noisy failures: Use -v, -s, and --report=source to identify which sniff and property produced a violation before changing code or configuration.