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

By Kokil Thapa | Last reviewed: September 2026

Your pull requests should not die over brace placement. A consistent PHP coding standard with Laravel Pint and PHP-CS-Fixer removes that noise before review starts. On production Laravel web projects, I treat formatters as infrastructure—not optional tooling. They cut diff noise, speed reviews, and keep new hires productive from day one. This guide walks through setup, configuration, CI enforcement, and team adoption for Laravel 12 and 13 on PHP 8.3 or higher.

Teams evaluating engineering maturity often look at this first. If you plan to hire a Laravel developer in Nepal, automated style enforcement signals a maintainable codebase. The same applies when building internal capacity for APIs, portals, or eCommerce systems.

How do you configure Laravel Pint for automatic PHP coding standard enforcement?

Laravel Pint wraps PHP-CS-Fixer with opinionated defaults aligned to Laravel conventions. It is the fastest path to a working PHP coding standard with Laravel Pint and PHP-CS-Fixer stack on any Laravel 12 or 13 application. Unlike raw PHP-CS-Fixer, Pint needs no config file to start.

Installation and basic usage

Pint ships with new Laravel 12 and 13 projects. For older codebases, install it via Composer 2.10:

composer require laravel/pint --dev

Run Pint to format all PHP files using the Laravel preset:

./vendor/bin/pint

Preview changes without writing files. This mode returns a non-zero exit code when violations exist:

./vendor/bin/pint --test

That exit code is what CI pipelines rely on. On a legal-tech portal I maintained, adding this to a pre-commit hook surfaced dozens of style violations accumulated during rapid feature work.

Customizing Pint configuration

Most production projects need minor tweaks. Create pint.json in your project root:

{
    "preset": "laravel",
    "rules": {
        "ordered_imports": {
            "sort_algorithm": "alpha"
        },
        "no_unused_imports": true,
        "single_quote": true,
        "array_syntax": {
            "syntax": "short"
        }
    },
    "exclude": [
        "bootstrap/cache",
        "storage",
        "vendor"
    ]
}

The preset option supports laravel, per (PER-CS), psr12, and empty. Use laravel for framework apps and per for standalone libraries. The exclude array keeps Pint away from cache and vendor directories. See the official Laravel Pint documentation for the full rule list.

Integrating Pint into your development workflow

Manual runs fail within weeks. Automate at two levels:

1. Git pre-commit hook: Use Git hooks with lefthook or husky to run ./vendor/bin/pint --dirty. The --dirty flag formats only changed files for instant feedback.
2. CI pipeline gate: Add ./vendor/bin/pint --test as a required job. Fail the pipeline when style violations exist. This catches hook bypasses and direct pushes.

On Deployer 7 releases, I add a lint stage before deploy. That blocks shipping code that violates team standards even when local hooks were skipped.

When should you choose PHP-CS-Fixer over Laravel Pint?

Pint excels for Laravel-centric teams. PHP-CS-Fixer offers deeper control when requirements outgrow Pint's JSON surface. Pick the right layer of your PHP coding standard with Laravel Pint and PHP-CS-Fixer stack early to avoid mid-project tool swaps.

Scenarios favoring PHP-CS-Fixer

• Non-Laravel projects: Symfony, Slim, or vanilla PHP benefit from framework-agnostic presets and 200+ fixers.
• Custom rule sets: Docblock formatting, file headers, or strict type ordering need full PHP-CS-Fixer access.
• Monorepos: Large mixed repositories gain from path filtering and parallel processing.
• Legacy codebases: Incremental rule rollout across directories requires fine-grained path modes.

Configuration example for PHP-CS-Fixer

Create .php-cs-fixer.dist.php in your project root:

<?php

$finder = PhpCsFixer\Finder::create()
    ->in([__DIR__ . '/app', __DIR__ . '/src'])
    ->exclude(['cache', 'generated']);

return (new PhpCsFixer\Config())
    ->setRules([
        '@PER-CS' => true,
        'declare_strict_types' => true,
        'global_namespace_import' => [
            'import_classes' => true,
            'import_functions' => false,
        ],
        'header_comment' => [
            'header' => 'Copyright (c) 2026 Your Company',
        ],
    ])
    ->setFinder($finder)
    ->setCacheFile('.php-cs-fixer.cache');

Install via Composer:

composer require friendsofphp/php-cs-fixer --dev

Run with diff output so teams see proposed changes before applying them:

./vendor/bin/php-cs-fixer fix --diff --verbose

Add .php-cs-fixer.cache to .gitignore. The PHP-CS-Fixer repository documents every available fixer and preset option.

What are the key differences between Laravel Pint and PHP-CS-Fixer?

Both tools share fixer technology under the hood. Their operational trade-offs differ in ways that matter on real projects. This table reflects practical usage across production systems in 2026.

I default to Pint on every Laravel project unless a specific rule forces PHP-CS-Fixer. That reduced setup burden helps full-stack development teams in Nepal onboard faster. Pair formatters with PHPStan static analysis for a complete quality gate—not style alone.

Both tools align with PSR-12 and PER-CS standards from PHP-FIG. Pint's Laravel preset extends those baselines with framework-specific conventions.

How do you integrate PHP code formatters into CI/CD pipelines?

Local enforcement alone is insufficient. Developers skip hooks, work offline, or push to protected branches. CI is the final gatekeeper for your PHP coding standard with Laravel Pint and PHP-CS-Fixer.

GitLab CI example

Add a dedicated lint stage to your pipeline. This pattern matches the GitLab CI setup for Laravel I use on shared EC2 infrastructure:

stages:
  - lint
  - test
  - deploy

php-lint:
  stage: lint
  image: php:8.4-cli
  script:
    - composer install --no-interaction --prefer-dist
    - ./vendor/bin/pint --test
  allow_failure: false

For PHP-CS-Fixer, replace the script line with ./vendor/bin/php-cs-fixer fix --dry-run --diff. The --dry-run flag mirrors Pint's --test behavior.

GitHub Actions example

name: PHP Code Style
on: [push, pull_request]

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

Place the lint job before tests and deploy stages. Style failures should block merges, not warn. See GitLab CI for PHP projects for caching Composer dependencies in pipelines.

Preventing merge conflicts from formatting

Formatting changes interleaved with feature work create painful rebases. Mitigate with three practices:

1. Dedicated formatting PRs: When adopting a new tool, submit one PR that formats the entire codebase. Merge quickly and rebase open branches.
2. Blame ignore revisions: List formatting-only commit hashes in .git-blame-ignore-revs. VS Code and PhpStorm read this file automatically.
3. Branch protection rules: Require the lint job to pass before merging. Never make style checks optional on mature projects.

How do you handle PHP coding standards in mixed-team environments?

Configuration solves half the problem. Team adoption determines whether your PHP coding standard with Laravel Pint and PHP-CS-Fixer actually sticks. After rolling these tools out across solo founders and agency teams, a few patterns separate successful adoptions from abandoned configs.

Onboarding new developers

Document setup in your project README—not a wiki page that goes stale. Include:

• Exact Composer commands to install dependencies
• IDE plugin recommendations for VS Code and PhpStorm
• Why specific rules were chosen over alternatives
• A link to the config file so developers can read rules directly

When hiring remotely across Nepal and international clients, this cuts onboarding from days to hours. A developer joining a Laravel API project should write features in hour one—not debug formatter conflicts.

Handling disagreements about rules

Style debates waste review energy. Use a simple decision framework:

1. Default to tool presets: Arguing against PSR-12 or Laravel conventions needs justification. Personal preference is not enough.
2. Vote once, enforce forever: Hold one meeting to finalize custom rules. Revisit quarterly, not per pull request.
3. Automate debatable items: If two developers disagree on import ordering, let the tool decide. Reviewers focus on architecture and correctness.

Legacy codebase migration strategy

Strict formatting on a decade-old codebase generates thousands of changes. Approach incrementally:

1. Phase 1: Enable safe rules only—indentation, spacing, braces. Format everything. Commit as a single style baseline revision.
2. Phase 2: Enable structural rules on new and modified files via Pint's --dirty mode or PHP-CS-Fixer path filtering.
3. Phase 3: Backfill remaining files during regular refactoring. Tie formatting to feature work for meaningful diffs.

This phased approach kept PRs reviewable on a legal services platform I modernized. Each phase produced manageable changes instead of one unreviewable wall of whitespace.

Editor integration for real-time feedback

Waiting until commit or CI is too late. Configure editors to format on save:

VS Code (settings.json):

{
    "editor.formatOnSave": true,
    "[php]": {
        "defaultFormatter": "junstyle.php-cs-fixer",
        "editor.tabSize": 4
    }
}

PhpStorm: Enable Settings → PHP → Quality Tools → PHP CS Fixer → Format on Save. Point to your project's binary and config file.

Real-time formatting removes an entire category of review comments. Your PHP coding standard with Laravel Pint and PHP-CS-Fixer becomes invisible to daily workflow. Developers stop thinking about style because the tool handles it continuously.

Combine formatters with Laravel best practices and modern architecture patterns for code that reads consistently and behaves predictably. Use the JSON formatter when validating pint.json syntax during config edits.

Key Takeaways

• Install Laravel Pint on Laravel 12/13 projects first; reach for PHP-CS-Fixer only when you need rules Pint cannot expose.
• Run ./vendor/bin/pint --test in CI with allow_failure: false so style violations block merges.
• Use --dirty in pre-commit hooks to format only changed files and keep feedback instant.
• Migrate legacy codebases in three phases—baseline PR, new files only, then backfill during refactors.
• Configure format-on-save in your IDE so developers never manually fix indentation again.
• Pair style enforcement with static analysis and a testing pipeline for full code quality coverage.

People Also Ask

Does Laravel Pint replace PHP-CS-Fixer?

No. Pint is a Laravel-focused wrapper built on PHP-CS-Fixer. It simplifies setup for Laravel teams but hides many advanced fixers. Keep PHP-CS-Fixer when you need custom headers, path-specific rules, or non-Laravel projects.

Can you run Laravel Pint and PHP-CS-Fixer together?

Technically yes, but avoid it. Running both creates conflicting rules and double-formatting churn. Pick one tool per repository. Most Laravel teams use Pint exclusively unless a specific rule forces PHP-CS-Fixer.

What PHP version do Pint and PHP-CS-Fixer require in 2026?

Laravel Pint requires PHP 8.2 or higher on Laravel 12, and PHP 8.3 or higher on Laravel 13. PHP-CS-Fixer 3.x supports PHP 8.2 through 8.5. Match your CI image to your production PHP-FPM version.

How do you fix a failed Pint check in CI?

Run ./vendor/bin/pint locally without --test, review the diff, commit the formatting changes, and push. Never disable the CI check—fix the code instead. For large backlogs, open a dedicated formatting PR first.

Start enforcing your PHP coding standard today

A PHP coding standard with Laravel Pint and PHP-CS-Fixer pays off immediately. You get cleaner diffs, faster reviews, and smoother onboarding. Install Pint in your current Laravel project today. Run it once to establish a baseline. Add the test command to CI tomorrow morning.

For non-Laravel work or advanced rule needs, adopt PHP-CS-Fixer with a documented config file. The setup takes less than an afternoon and compounds across every future pull request. If your team needs help wiring formatters into Deployer pipelines or auditing an existing codebase, contact us about your project. I regularly help teams in Nepal and worldwide build workflows that scale without burning out developers—and you can also reach out directly to discuss specifics.