- How do I install pluswerk/grumphp-config in a Laravel project?
- Run composer require pluswerk/grumphp-config --dev. On install the package generates grumphp.yml, rector.php, phpstan.neon and phpstan-baseline.neon, pulling in project-specific resources where necessary. Because the current line is 1.x-era major bump from 10.x, pin the version explicitly (for example :11.2.0 or ^11.2) and upgrade on a branch using composer update --with-dependencies.
- Which files does pluswerk/grumphp-config generate automatically?
- It creates grumphp.yml, rector.php, phpstan.neon and phpstan-baseline.neon in your project root, and it requires project-specific resources if necessary. The generated grumphp.yml is the central place where all task configuration lives, so you can edit it directly. Because these files are generated, review the diff after each package upgrade instead of assuming the defaults are unchanged.
- How do I override the default GrumPHP settings in the generated grumphp.yml?
- Open the generated grumphp.yml and change the settings in place; the README explicitly points you there for overrides. Tasks are toggled in the standard tasks: block, and ordering is controlled through metadata.priority when one task must run before another. No plugin or extension API is involved, so any override you make is plain GrumPHP configuration.
- Does pluswerk/grumphp-config support Laravel 10 and PHP 8.5?
- The 11.2.0 release does not change version constraints, and PHP 8.5+ with Laravel 10+ compatibility is reported as unchanged. However, the published notes only cover 11.1.1 through 11.2.0, and the 10.x to 11.x major step may carry minimum PHP or GrumPHP version changes that must be reviewed before adoption. Test the install on a branch and confirm the resolved PHP and GrumPHP constraints in your composer.lock.
- What is the composer_validate_autoload task and why is it on by default?
- It is a new shared GrumPHP task, added in PR #124, that wraps the upstream phpro/grumphp v2.x autoload validation to catch autoload drift when classes are renamed or moved without a fresh composer dump-autoload. That drift typically surfaces late, in CI test runs or as class-not-found errors in production, so catching it pre-commit is genuinely useful. It is enabled in the shared configuration, meaning every consumer inherits it on upgrade; disable it or set a lower priority if your project uses classmap-heavy legacy app code, generated proxies or multi-namespace modules.
- Can I disable specific GrumPHP tasks added by this config package?
- Yes. Every task, including composer_validate_autoload, is declared in the tasks: block of the generated grumphp.yml, so you can remove it or set it to false. You can also steer execution order with metadata.priority, for example running autoload validation before static analysis. Keep a note of any tasks you disable so a later regeneration of grumphp.yml does not silently re-enable them.
- Does pluswerk/grumphp-config work in CI pipelines such as GitHub Actions or GitLab CI?
- Yes, GrumPHP remains CI-agnostic, so you invoke it the same way as any other GrumPHP setup, typically vendor/bin/grumphp run in a pipeline step. The new autoload validation adds one Composer process per run, so measure wall-clock impact and place that task in the parallel block rather than the serial block. Also confirm from the upstream task docs whether the check runs with --no-scripts, because Laravel's post-autoload-dump artisan package:discover hook can otherwise fire in build stages that lack .env or APP_KEY.
- What Laravel-specific PHPStan, Pint and Rector setup do I still need?
- This package does not bundle framework-aware rules. PHPStan still needs phpstan/extension-installer plus Laravel rules such as Larastan, Pint still needs to override PHP-CS-Fixer, and Rector still needs the Laravel rule sets. There are also no shared tasks for route:list, migrate:status, config:cache, artisan optimize or pint, so those require custom tasks: entries in your grumphp.yml.
- Is upgrading pluswerk/grumphp-config from 10.x to 11.x a breaking change?
- It is a major version step, and the published notes for 11.2.0 only cover the 11.1.1 to 11.2.0 range, so the contents of the 10.x to 11.x jump, such as minimum PHP and GrumPHP versions, config key renames or changed task defaults, are not evidenced and must be reviewed directly. Upgrading also brings the default-on composer_validate_autoload task, which can turn a routine upgrade into a failing one for non-standard autoload setups. Pin explicitly, upgrade on a branch, and run the full GrumPHP task list before merging.
- What are the alternatives to pluswerk/grumphp-config for Laravel code quality?
- You can assemble your own grumphp.yml on top of phpro/grumphp, which is the same execution model this package wraps, or use another shared GrumPHP config preset. For Laravel-specific rules, pairing Pint, Larastan and the Rector Laravel sets gives framework-aware checks that this package does not provide out of the box. The trade-off is manual maintenance of the task list, whereas this package regenerates its config and tracks upstream GrumPHP tasks, so pin versions and review changelogs either way.