Weave Code
Pint Laravel Package
laravel/pint
Laravel Pint is an opinionated PHP code style fixer for minimalists. Built on PHP-CS-Fixer, it makes it simple to ensure your code style stays clean and consistent, with zero configuration required and an easy-to-use CLI that works in any Laravel or PHP project.
An opinionated code formatter for PHP.
Frequently asked questions about Pint
- What is Laravel Pint used for?
- Laravel Pint is an opinionated PHP code style fixer built on top of PHP-CS-Fixer. It formats your PHP files to a consistent style with zero configuration, using sensible defaults tuned for Laravel projects. Most teams run it locally before committing and as a style gate in CI.
- How do I install Laravel Pint in a Laravel project?
- Install it as a development dependency with composer require laravel/pint --dev and commit the resulting lockfile change. You then run vendor/bin/pint from your project root. For repositories without Composer, Pint is also distributed as a PHAR.
- Does Laravel Pint work outside of Laravel projects?
- Yes. Pint is a standalone CLI tool built on PHP-CS-Fixer, so it can format most Composer-based PHP codebases, including libraries and non-Laravel frameworks. The default preset is opinionated toward Laravel conventions, but you can adjust presets and rules in a pint.json file.
- Which PHP versions does Laravel Pint support?
- Pint tracks PHP and PHP-CS-Fixer support closely, and recent releases include PHP 8.4 support with partial PHP 8.5 support. Because compatibility moves with each release, pin a known-good Pint version per repository and verify it against your project's PHP matrix in CI before upgrading.
- How do I configure Laravel Pint with a pint.json file?
- Create a pint.json at your project root to choose a preset, add or exclude rules, and define path exclusions for generated or vendor directories. Most projects can start with the Laravel preset and only add overrides where needed. Keep the shared config in version control so local runs and CI stay in sync.
- How do I run Laravel Pint in CI as a style check?
- Run vendor/bin/pint --test in your pipeline so the command exits non-zero when files need formatting, failing the build. Enable this only after applying a single baseline formatting commit, otherwise the first run will fail across the whole codebase. On large repositories, use parallel execution and consider checking only changed files to control CI time.
- Will adopting Laravel Pint cause large merge conflicts?
- The first run reformats many files at once, so merge conflicts are likely if it is mixed with functional work. Apply the baseline formatting in an isolated pull request and merge it quickly, then enable CI enforcement. After that, formatting diffs stay small and predictable.
- What is the difference between Laravel Pint and PHP-CS-Fixer?
- PHP-CS-Fixer is the underlying engine and offers extensive configuration, while Pint wraps it with an opinionated preset and near-zero configuration. Moving from PHP-CS-Fixer to Pint is not a one-to-one rule mapping, so review existing rules and expect some style changes. Pint is simpler to adopt but less configurable by design.
- Is Laravel Pint safe to use in production deployments?
- Pint is a development-only CLI tool and should be installed as a dev dependency, so it is never deployed or executed at runtime. That keeps runtime and security risk low. The real risks are formatting churn, rule changes across upgrades, and pipeline disruption if enforcement is enabled too early.
- How should we manage Laravel Pint upgrades across many repositories?
- Pin the Pint version per repository and treat upgrades as controlled changes, testing them in CI against your PHP matrix first. Publish a shared pint.json template and a rollout checklist, and assign ownership to a platform or developer-productivity team. Review release notes for preset and PHP-CS-Fixer compatibility changes before rolling out.
Weaver
How can I help you explore Laravel packages today?