- How do I install pekral/phpcs-rules with Composer?
- Install it as a development dependency with composer require --dev pekral/phpcs-rules. Because the package is a PHP_CodeSniffer ruleset and not runtime library code, it belongs in require-dev rather than require. After installation, point your phpcs.xml at the bundled ruleset instead of copying sniff configuration into each repository.
- How do I reference the pekral/phpcs-rules ruleset in my phpcs.xml?
- Add a rule element to your phpcs.xml that references the installed standard, for example <rule ref="pekral/phpcs-rules"/> or the explicit ruleset path shipped by the package. This is the drop-in integration the package is designed for, so you avoid duplicating sniffs across repositories. Keep your project-specific excludes and file paths in the same file.
- Does pekral/phpcs-rules support Laravel projects?
- Yes. The package is a curated coding standard aimed at Laravel and general PHP projects. It adds no framework runtime code, so it works in any Laravel repository that already runs PHP_CodeSniffer. Teams use it to keep style checks consistent across multiple Laravel repositories.
- Which PHP version does pekral/phpcs-rules require?
- Version 0.5.x declares a php constraint of ^8.5, so Composer will refuse to resolve it on PHP 8.4 and below. If your CI images or developer machines are not yet on 8.5, pin an earlier line such as ~0.4.8. This constraint applies to the environment running static analysis, not to the PHP version your application runs in production.
- Is pekral/phpcs-rules safe to use in production?
- It is developer tooling only, so it ships no runtime code and cannot affect production requests. The practical impact is limited to lint results in local development and CI pipelines. Install it with require-dev and keep it out of production deployments and runtime image builds.
- Will upgrading to pekral/phpcs-rules 0.5.x break my build?
- It can. The 0.5 ruleset re-enables SlevomatCodingStandard.Functions.StaticClosure and excludes Classes.ReadonlyClass, which may surface new violations without any change to your code. That is a minor release under semver but a lint ruleset change can still turn a green build red. Run PHPCS against your codebase before merging the upgrade.
- How do I run pekral/phpcs-rules in a CI pipeline?
- Require the package as a dev dependency, then run vendor/bin/phpcs against your configured phpcs.xml in the CI job. Because 0.5.x needs PHP 8.5, that lint job must run on an 8.5-capable image, which can be a dedicated container separate from your application runtime. Fail the job on violations so style regressions block merges.
- Can I customize or exclude rules from the pekral/phpcs-rules ruleset?
- Yes. The ruleset is built on standard PHP_CodeSniffer sniffs and supports configurable rule selection for different project needs. You can reference only the rules you want, exclude paths, or override severity in your own phpcs.xml. That makes it practical to adopt the standard gradually across repositories.
- Should I pin pekral/phpcs-rules to an exact version?
- Pinning is advisable, especially while 0.5.x requires PHP 8.5. Use a tight constraint such as ~0.4.8 with a comment in composer.json recording the PHP 8.5 gate and a review date. Also exclude the package from automated minor-bump merges in your dependency bot, otherwise a ruleset change can silently alter lint results.
- What are the alternatives to pekral/phpcs-rules?
- Alternatives include running PHP_CodeSniffer directly with your own ruleset, using Slevomat Coding Standard (which this package builds on), or adopting Laravel Pint for opinionated Laravel formatting. The trade-off is that a shared package like pekral/phpcs-rules avoids duplicating sniff configuration across repositories. Choose based on whether you need one consistent standard across many repos or a single-project formatter.