Phpcodesniffer Composer Installer Laravel Package

Getting Started

1. Install the plugin as a dev dependency in your Laravel project:

   composer require --dev dealerdirect/phpcodesniffer-composer-installer:"^1.0"
   

2. When prompted by Composer (v2.2+), grant permission for plugin execution — or pre-approve it:

   composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
   

3. Require one or more PHPCS standards packages (e.g., wp-coding-standards/wpcs, phpcompatibility/php-compatibility, laravel/breeze’s bundled standards) in require-dev.
4. Run composer install — standards are auto-registered with PHP_CodeSniffer; verify with:

   ./vendor/bin/phpcs -i
   

   You should see your newly installed standards in the list.

Implementation Patterns

• Standard installation: Add coding standards directly in composer.json’s require-dev without manual installed_paths configuration.

  "require-dev": {
      "dealerdirect/phpcodesniffer-composer-installer": "^1.0",
      "wp-coding-standards/wpcs": "^3.0",
      "phpcompatibility/php-compatibility": "^9.0"
  }
  

• CI/CD automation: Hook the plugin manually into Composer scripts for deterministic builds:

  "scripts": {
      "post-install-cmd": [
          "@install-codestandards"
      ],
      "install-codestandards": [
          "PHPCSStandards\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run"
      ]
  }
  

  Then call via composer install-codestandards.
• Nested standards discovery: If you develop company-wide standards (e.g., acme/phpcodesniffer-custom), declare "type": "phpcodesniffer-standard" and place standards in subdirectories ≤3 levels deep.
• Transitive dependency handling: Your custom standard’s composer.json can also require this plugin (using flexible version constraints like "*" or "^0.7 || ^1.0"), ensuring dependent standards auto-install for consumers.

Gotchas and Tips

• ✅ Permissions: Composer 2.2+ blocks plugin execution by default. Always set allow-plugins early (e.g., in Dockerfile or CI config) to avoid interactive prompts.
• ⚠️ Global vs. local plugin: If this plugin is installed globally, Composer may use that version instead of the project-local one — which could cause version mismatches. Prefer local-only usage.
• 🔍 Search depth: Default directory traversal depth is 3. If your standards are nested deeper, bump it explicitly:

  "extra": {
      "phpcodesniffer-search-depth": 5
  }
  

• 🛠 Debugging: To confirm registration, run:

  ./vendor/bin/phpcs -i
  ./vendor/bin/phpcs -e -v  # show installed rulesets + paths
  

• 🧱 Standard packaging requirements: Ensure your custom standard’s composer.json includes:

  "type": "phpcodesniffer-standard",
  "require": {
      "squizlabs/php_codesniffer": "^3.13 || ^4.0"
  }
  

• 📦 Dependency hell prevention: If your standard is meant to be reused, avoid pinning this plugin strictly (e.g., avoid ^1.0 while another package requires ^0.7). Use "*" or broad poly-fill constraints.
• 🧪 Test in CI: Add a CI step that validates standards are discoverable:

  ./vendor/bin/phpcs -i | grep -q 'YourStandardName' || exit 1
  

• 🐞 Known quirks: In deep monorepos or frameworks like Laravel + Inertia + Vue (with node_modules inside resources), ensure your vendor/ and node_modules/ are not interfering —PHPCS search depth only applies to Composer dependencies, not arbitrary folders.