- Does facile-it/facile-coding-standard work with Laravel 9 or older (PHP 8.1/7.4)?
- No, this package requires PHP 8.2+ (as of v1.5.0), which aligns with Laravel 10+. If you’re on Laravel 9 or older, you’ll need to upgrade or use an alternative like PHP-CS-Fixer directly with a custom config. The installer will fail on unsupported PHP versions.
- How do I disable risky rules like `class_keyword` or `long_to_shorthand_operator` that might break existing code?
- Create a `.php-cs-fixer.php` file in your project root and override the risky rules by modifying the config loaded from `.php-cs-fixer.dist.php`. For example, add `$config->getRules()['class_keyword'] = false;` to disable it. The auto-generated config includes comments on how to customize rules.
- Can I integrate this into GitHub Actions or Laravel Forge for CI/CD checks?
- Yes, the package adds `cs-check` and `cs-fix` scripts to your `composer.json`, which you can call directly in CI pipelines. For GitHub Actions, use a step like `- run: composer cs-check` to enforce checks. For Laravel Forge, add a deploy hook or use a custom script in your `deploy.php`.
- Will this break my existing PHPCBF or PHPCS setups if I already have them configured?
- It depends. The installer generates a new `.php-cs-fixer.dist.php` config, so you’ll need to merge or replace your existing PHPCS/PHPCBF rules. Start by running `composer cs-check` in a staging environment to see conflicts, then manually adjust `.php-cs-fixer.php` to align with your team’s standards.
- Does this package support Blade template formatting or only PHP files?
- Currently, this package only enforces PHP coding standards (PSR-12/PER-CS 3.0) and ignores Blade files. For Blade-specific formatting, you’ll need additional tools like Laravel Pint or custom PHPCS rulesets. The autoload detection skips non-PHP files by default.
- How do I run a dry fix to preview changes before committing?
- Use the `cs-check` script added to your `composer.json`: run `composer cs-check` in your terminal. This executes `php-cs-fixer` in dry-run mode, showing diffs of changes without modifying files. For actual fixes, use `composer cs-fix` in a feature branch.
- Are there performance concerns with the Rector integration in v1.5.0+?
- Rector is optional and only relevant if you’re using it for refactoring. If you don’t need Rector, disable it in `.php-cs-fixer.php` by removing or commenting out the relevant config. For large codebases, running `composer cs-fix` may take longer, so test it in CI first to gauge performance.
- What’s the best way to handle bulk fixes for a large Laravel codebase?
- Start by running `composer cs-fix` in a dedicated branch to auto-correct issues. Commit the changes incrementally to avoid overwhelming your team. For risky rules, disable them first (via `.php-cs-fixer.php`) and manually review changes. Use `git add -p` to stage fixes selectively.
- Can I use this with PHP 8.1 or 8.0 despite the PHP 8.2 requirement?
- No, the package explicitly requires PHP 8.2+ due to dependencies like PHP-CS-Fixer 3.88+. If you’re stuck on PHP 8.1/8.0, downgrade to PHP-CS-Fixer 3.30+ and use a custom config. However, some PER-CS 3.0 rules may not work correctly on older PHP versions.
- How do I exclude specific directories or files from the coding standard?
- Modify the `finder` section in `.php-cs-fixer.php` to exclude paths. For example, add `$config->getFinder()->exclude(['path/to/dir', 'vendor/'])` to skip directories. The auto-generated config already excludes `vendor/` and `node_modules/` by default.