Weave Code
Coding Standard Laravel Package
cline/coding-standard
Opinionated PHP-CS-Fixer configuration with custom fixers and presets for modern PHP projects. Enforces strict coding standards, naming conventions, and architectural patterns, with PHPDoc, Rector, and EasyCodingStandard support.
Centralized coding standards for Cline projects using PHP-CS-Fixer, ECS, and Rector
Frequently asked questions about Coding Standard
- What is cline/coding-standard and what does it do?
- It is an opinionated PHP-CS-Fixer configuration package that provides presets, custom fixers, a preconfigured finder, and architecture-focused rules for modern PHP projects. It is intended as a dev-only Composer dependency that standardizes formatting and coding conventions across repositories. It is not runtime infrastructure and should not affect production behavior.
- Does cline/coding-standard support Laravel applications?
- It fits Composer-based Laravel projects that run on PHP 8.4 or newer. The package is not Laravel-specific and does not document dedicated presets for Blade templates, migrations, Artisan commands, service providers, or DTO conventions. Teams should validate the custom fixers against Laravel idioms before organization-wide adoption.
- How do I install cline/coding-standard in a Laravel project?
- Install it as a development dependency with composer require cline/coding-standard --dev. Add a .php-cs-fixer.dist.php configuration file, then run vendor/bin/php-cs-fixer fix --dry-run --diff to preview changes. After validating the diff, run the fixer and enforce the check in CI.
- What PHP version does cline/coding-standard require?
- The package requires PHP 8.4 or newer. That requirement can exclude older Laravel LTS branches and may block adoption across mixed-version portfolios. Confirm which repositories are on PHP 8.4+ before planning a rollout.
- Can I use cline/coding-standard alongside Laravel Pint?
- Coexistence with Laravel Pint needs explicit validation to avoid duplicate formatters and conflicting rule ownership. The safer approach is to designate one formatter as authoritative and decide whether this package replaces Pint, feeds rules into Pint where possible, or is limited to repositories without Pint. A pilot repository is the best way to test the overlap.
- What presets and custom fixers are included in cline/coding-standard?
- The package includes Standard, PHPDoc, PHPUnit, and Ordered presets plus custom architecture and naming-convention fixers. The PHPDoc preset includes an 80-column docblock prose wrapper, and the bundled Rector preset enables PHP 8.5 pipe-operator migrations. The Standard preset removes @author tags, @version tags, and file-level license headers by default, with opt-in support for the legacy rules.
- Is cline/coding-standard safe to run in production?
- It is a code-quality and formatting tool, so it should be installed as a dev dependency and should not affect production runtime behavior. The main operational risk is a large one-time formatting diff that can create merge conflicts or CI friction during adoption. Use a pilot repository and a formatting freeze window before broad rollout.
- How do I enforce cline/coding-standard in CI?
- Run vendor/bin/php-cs-fixer fix --dry-run --diff as a CI quality gate. This works naturally with GitHub Actions, GitLab CI, Laravel Forge deploy pipelines, and local pre-commit hooks. Monitor pipeline duration and merge conflicts if custom fixers or a large formatting pass are introduced.
- What are the adoption risks of using cline/coding-standard?
- The package has limited ecosystem maturity, including zero stars and dependents in the assessment, and it is maintained by a single maintainer. A future-dated release should be validated against Packagist and GitHub before relying on release cadence. Default removal of @author, @version, and license headers may conflict with legal, audit, or open-source contribution policies, so teams should plan an internal fork or fallback.
- What alternatives exist to cline/coding-standard?
- Alternatives include raw PHP-CS-Fixer, Laravel Pint, EasyCodingStandard, and Rector, depending on whether you need formatting, architecture rules, or automated refactoring. The key decision is to choose a single authoritative formatter and avoid overlapping rule ownership. Evaluate alternatives against your PHP version requirements and existing Laravel tooling.
Weaver
How can I help you explore Laravel packages today?