Standard Bundle Laravel Package

Getting Started

• Install the bundle as a dev dependency and let the Flex recipe lay down the tooling files:

  composer require --dev smartbooster/standard-bundle
  composer recipes:install smartbooster/standard-bundle --reset --force
  

  As of v1.8.2 the set of copied files is unchanged — you get the updated phpstan.neon and make/qualimetry.mk only by re-running the recipe with --reset --force.
• Read docs/rules.md first. It is the catalogue: every rule the bundle checks, what it reads, and what status it can report (ok / ko / the new info).
• Then docs/phpstan.md and CLAUDE.md, which document the PHPStan command and where the level lives. Both were realigned in this release, so they are now trustworthy.
• First use case: run the qualimetry make target (e.g. make phpstan) on a fresh checkout and read the report. The rules that concern CI only read .gitlab-ci.yml and the make targets it calls — nothing is executed, so it is safe to run on any machine or in a sandbox.
• The infra side is checked by infra.mysql-version: it compares MYSQL_VERSION from .env (patch version included) with the value passed to doctrine.dbal.server_version. Fix that pair early; it is the cheapest rule to satisfy.

Implementation Patterns

• Level lives in the config, not the command line. phpstan.neon now declares level: 10 under parameters, and make/qualimetry.mk no longer passes --level. Per-project overrides belong in phpstan.neon (parameters.level), not in a Makefile variable or a CLI flag — a level passed on the command line is not seen by the phpstan.level rule and will silently disagree with the report.
• Baseline workflow. Generate with make phpstan-generate-baseline, commit the baseline, and treat the resulting debt figure as the info status. Info is a number to watch, not a failure to fix — don't wire it into a CI gate.
• Rule-by-rule configuration. phpstan.extensions, phpstan.disallowed-calls, php.cs-fixer, psalm.taint, symfony.lints and php.composer-check are all configured declaratively (neon config, .php-cs-fixer rules, composer scripts). Enabling a rule and satisfying it are the same edit, which keeps reviews small.
• Keep the CI contract stable. The CI-facing rules parse .gitlab-ci.yml and the make targets it invokes. Renaming a make target or moving a job breaks the check without breaking the build — treat target names as part of your public interface.
• .env is the source of truth for production versions. MYSQL_VERSION must be the full x.y.z (patch included) and must match doctrine.dbal.server_version. Bump both in the same commit, and prefer reading from .env rather than hardcoding in doctrine.yaml.
• Upgrade loop. After any bundle bump: git commit → composer recipes:install ... --reset --force → git diff → re-apply local deviations. Because this release has no new dotted manifest, Composer will not nudge you; the re-run is manual and deliberate.

Gotchas and Tips

• The CLI --level flag is a trap. It still works for PHPStan itself but is invisible to the phpstan.level rule, so your report and your build can disagree. Set the level only in phpstan.neon.
• --reset --force overwrites local edits. Commit before running it. Any house-specific tweak to phpstan.neon or make/qualimetry.mk (extra ignore errors, custom targets) will be clobbered — record deviations in a note or a separate included neon file.
• No new dotted manifest means no automatic recipe update. This is the main "why didn't I get the fix?" confusion for v1.8.2: the recipe file list is identical, so the only signal is this changelog. Re-run recipes:install explicitly.
• MYSQL_VERSION needs the patch component. A value like 8.0 will fail the infra.mysql-version comparison even though MySQL itself accepts it. Same for doctrine.dbal.server_version.
• Green report ≠ green pipeline. The CI rules statically read .gitlab-ci.yml and the make targets; they never run the pipeline. A passing qualimetry report tells you the wiring looks right, not that the jobs succeed.
• Info status is diagnostic, not actionable. It quantifies debt (baseline entries, disabled php-cs-fixer rules). Track it over time as a trend; do not fail builds on it or "fix" it by deleting baseline entries.
• Debugging a stale level: if the reported PHPStan level looks wrong after an upgrade, check parameters.level in phpstan.neon first, then confirm make/qualimetry.mk is the recipe version (no --level argument present). Those two are the whole story since v1.8.2.