PHP Coding Standard with Laravel Pint and PHP-CS-Fixer

By Khimananda Oli | Last reviewed: August 2026

Maintaining a consistent PHP coding standard with Laravel Pint and PHP-CS-Fixer eliminates subjective code review comments and reduces cognitive load across distributed teams. While Laravel Pint offers zero-config simplicity for framework projects, PHP-CS-Fixer provides the granular control required for complex legacy codebases or strict compliance environments. Choosing the right tool—and integrating it correctly into your development workflow—ensures every commit meets your quality baseline before it ever reaches production.

How do you configure a PHP coding standard with Laravel Pint and PHP-CS-Fixer?

Configuration determines whether your tooling fights you or works silently in the background. For most Laravel applications built in 2026, Pint is the pragmatic choice because it ships with sensible defaults that match the framework's conventions. You install it as a dev dependency and run it without any configuration file initially. However, real-world projects often need to exclude specific directories like storage, vendor, or generated migration files.

Setting up Laravel Pint

Create a pint.json file in your project root to customize behavior without cluttering your composer scripts. This configuration extends the base Laravel preset while ignoring test fixtures and legacy API responses that cannot be safely refactored yet.

{
    "preset": "laravel",
    "exclude": [
        "storage",
        "bootstrap/cache",
        "tests/Fixtures"
    ],
    "rules": {
        "ordered_imports": true,
        "no_unused_imports": true,
        "phpdoc_align": false
    }
}

Configuring PHP-CS-Fixer for granular control

When your team requires strict PSR-12 adherence or custom rules beyond Pint’s scope, PHP-CS-Fixer becomes necessary. Create a .php-cs-fixer.dist.php configuration file. This approach is common when integrating with DevSecOps workflows where code style intersects with security scanning requirements.

<?php

$finder = PhpCsFixer\Finder::create()
    ->in(__DIR__)
    ->exclude('vendor')
    ->exclude('storage');

return (new PhpCsFixer\Config())
    ->setRules([
        '@PSR12' => true,
        'array_syntax' => ['syntax' => 'short'],
        'concat_space' => ['spacing' => 'one'],
        'declare_strict_types' => true,
    ])
    ->setFinder($finder)
    ->setCacheFile('.php-cs-fixer.cache');

A common mistake is committing the cache file. Always add .php-cs-fixer.cache to your .gitignore to prevent environment-specific paths from causing CI failures.

Laravel Pint vs PHP-CS-Fixer: which tool should you choose?

Selecting between these tools depends on your team size, framework commitment, and tolerance for configuration maintenance. I have deployed both across dozens of production environments, and the decision matrix below reflects actual operational trade-offs rather than theoretical feature lists.

If you are building a new Laravel application or maintaining one that already follows framework conventions, start with Pint. Migrate to PHP-CS-Fixer only when you hit a specific limitation—such as needing to enforce strict types across a non-Laravel library or requiring a rule that Pint explicitly excludes. For teams managing Laravel performance optimization, Pint’s speed advantage during local development compounds significantly over hundreds of daily saves.

How do you automate code style checks in CI/CD pipelines?

Local formatting is optional; CI enforcement is mandatory. Without pipeline gates, style drift accumulates within days regardless of team agreements. When setting up CI/CD pipelines for Laravel, always run the formatter in check-only mode (--test for Pint, --dry-run for CS-Fixer). Never auto-fix in CI—this creates phantom commits that break blame history and confuse developers.

GitHub Actions example for Laravel Pint

This workflow runs on every pull request targeting main. It uses the official Pint action but fails the build if violations exist, forcing the developer to fix locally.

name: Code Style Check

on:
  pull_request:
    branches: [main]

jobs:
  pint-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.4'
          
      - name: Install Dependencies
        run: composer install --prefer-dist --no-progress
        
      - name: Run Pint Check
        run: ./vendor/bin/pint --test

GitLab CI example for PHP-CS-Fixer

For teams using GitLab, cache the CS-Fixer binary and result cache to avoid redundant downloads. The --diff flag outputs exactly which lines violate standards, making merge request comments actionable.

code-style:
  stage: test
  image: php:8.4-cli
  cache:
    key: cs-fixer-cache
    paths:
      - .php-cs-fixer.cache
  script:
    - composer install --no-dev --optimize-autoloader
    - vendor/bin/php-cs-fixer fix --dry-run --diff --stop-on-violation
  allow_failure: false

In practice, I recommend adding a "fix" script to your Makefile or Taskfile so developers can run make lint-fix locally before pushing. This reduces CI cycle time and prevents the frustration of waiting 5 minutes for a pipeline to fail on whitespace issues.

How do you integrate formatters with VS Code and PhpStorm?

IDE integration transforms code styling from a post-commit chore into an invisible background process. When developers see violations as they type, compliance rates approach 100% without managerial overhead.

• VS Code: Install the "Laravel Pint" extension by OpenSouth or "PHP CS Fixer" by Junstyle. Set "editor.formatOnSave": true in settings.json. For workspace consistency, commit a .vscode/settings.json specifying the default formatter per language.
• PhpStorm: Navigate to Settings → PHP → Quality Tools. For Pint, configure the path to vendor/bin/pint. For CS-Fixer, point to the binary and your config file. Enable "Reformat on Save" under Actions on Save. PhpStorm 2026+ includes native Pint support without plugins.
• Neovim: Use null-ls or conform.nvim with the pint or phpcsfixer formatter. Configure format-on-save in your Lua configuration to match your team's exact CLI flags.

A critical detail: ensure your IDE uses the same binary version as CI. Version mismatches cause the dreaded "it looks fine locally but fails in pipeline" loop. Pin versions in composer.json and use composer.lock religiously.