Standard Bundle Laravel Package

Technical Evaluation

smartbooster/standard-bundle is a development-tooling / quality-gate bundle, not a runtime library. It ships Composer recipes that copy config artifacts (phpstan.neon, make/qualimetry.mk, related docs) into consuming repositories and defines a rule catalogue enforced by Smart App. Architecture fit is therefore limited to the dev-dependency and CI layer: it has no bearing on application runtime, request handling, or data paths in a Laravel/PHP service. The value a TPM derives from it is standardisation of static analysis, taint analysis, CS, and CI linting across a repo fleet.

v1.8.2 is a configuration-and-documentation release with one behavioural change:

• PHPStan level ownership moves from the Makefile to phpstan.neon. make/qualimetry.mk no longer passes --level=10; parameters.level: 10 is now declared in the shipped phpstan.neon. Projects that had a lower in-file level but relied on the CLI flag to force 10 will silently change effective strictness in one direction or the other.
• Interaction with the phpstan.level rule. The release notes state a level given on the command line is not visible to the rule. Any consumer invoking PHPStan directly with --level will now be scored against the file value, producing a mismatch between actual strictness and reported compliance.
• New rule surface: infra.mysql-version (reads MYSQL_VERSION from .env, patch included, cross-checked against doctrine.dbal.server_version), plus documented code-quality rules (phpstan.baseline, phpstan.extensions, phpstan.disallowed-calls, psalm.taint, php.cs-fixer, symfony.lints, php.composer-check) and a new non-blocking info status.
• No new dotted manifest — the set of copied files is unchanged, so there is no new tracked-file surface and no orphan-manifest cleanup.

Technical risk: low runtime, medium CI blast radius. The prescribed upgrade command is composer recipes:install smartbooster/standard-bundle --reset --force, which overwrites phpstan.neon and make/qualimetry.mk unconditionally. Any project-local customisation of those two files (custom paths, excludePaths, bootstrap files, extension includes, baseline path, ignoreErrors, Makefile target overrides) is destroyed without warning. A PHPStan level increase to 10 will surface a wave of new findings, likely requiring a baseline regeneration that inflates the phpstan.baseline info figure. The infra.mysql-version rule's dependence on a checked-out .env is a concern for CI runners that inject configuration as environment variables rather than materialising a .env file — the rule may report nothing, or report a false negative, in exactly the environment where it matters.

Semver concern worth raising with the maintainer: a patch release changes effective static-analysis strictness and the mechanism by which it is configured. That is a minor-or-major-shaped change for consumers even though the package API is unchanged.

Key questions for the maintainer / owning team:

1. Is the --level removal a hard break — do the Make targets still honour a LEVEL/PHPSTAN_LEVEL variable if a team needs a temporary override?
2. What is the documented reconciliation path for teams with a customised phpstan.neon that cannot take the --reset --force overwrite verbatim?
3. Does infra.mysql-version degrade gracefully (skip / info) when .env is absent, or does it fail the gate?
4. Does an info status ever fail a pipeline, or is it purely advisory debt reporting? Can it be promoted to blocking per repo?
5. Which Laravel/PHP versions and PHPStan/Psalm majors are supported at v1.8.2, and is there a support matrix?
6. Is there a changelog contract committing to flag config-affecting changes as at least a minor bump?

Integration Approach

Stack fit: this is a natural fit for a Laravel/PHP organisation that already carries a shared quality baseline — it replaces per-repo bespoke PHPStan/CS/CI config with an upstream-maintained recipe. It assumes a Composer-scripted workflow, a Make-based task runner (make/qualimetry.mk, invoked from .gitlab-ci.yml), and GitLab CI as the observed pipeline source. Teams on GitHub Actions or without make will get partial value (the static-analysis config still applies; the CI-reading rules will find nothing to inspect).

Migration path and sequencing:

1. Freeze and diff first, upgrade second. In a single pilot repository, run composer recipes:install smartbooster/standard-bundle --reset --force on a throwaway branch and git diff phpstan.neon and make/qualimetry.mk against the pre-upgrade state. This is the single most important step — it quantifies exactly what local customisation is at risk before anything is forced.
2. Reconcile, don't accept. Re-apply any project-specific parameters (paths, excludes, bootstrap, extensions, baseline location) on top of the recipe output, keeping parameters.level: 10. If the team cannot absorb level 10 immediately, set the file value explicitly to the current effective level and track the increase as separate debt — do not reintroduce --level on the command line, since the phpstan.level rule will not see it.
3. Regenerate baseline deliberately. Run make phpstan-generate-baseline, review the delta size, and treat an unexpectedly large baseline as a signal to defer the level bump rather than to commit a swollen baseline.
4. Verify the toolchain end to end: make phpstan, make phpstan-generate-baseline, and the full pipeline on a branch, confirming that PHPStan is now reading level 10 from the file and that the phpstan.level rule agrees.
5. Roll forward in cohorts: pilot repo → shared template/boilerplate repo (so new projects are born compliant) → remaining fleet, batched by similarity of existing customisation.
6. Pin and record. Pin the dev dependency to v1.8.2, and land the reconciled phpstan.neon/qualimetry.mk in the template repo so future recipe runs converge rather than diverge.

Compatibility checkpoints: confirm the PHPStan major in each repo supports parameters.level (it has for a long time, but the CLI-flag removal is only safe on a version that reads it), confirm Psalm availability before enabling psalm.taint, and confirm whether dotenv/doctrine.dbal inspection is even relevant for repos with no database layer — the infra.mysql-version rule may be noise for API-only services and should be scoped or disabled with a recorded rationale.

Operational Impact

Maintenance: Low steady-state cost — the package is config, not code, and there is no runtime dependency to patch. The real maintenance burden is drift management: every repository now holds a copy of phpstan.neon and make/qualimetry.mk that can diverge from upstream. Because this release explicitly adds no new dotted manifest, the footprint is stable, but the reconciliation step in each upgrade is manual and recurring. Budget a small recurring task per release cycle per repo.

Support: Support burden concentrates on two things: "the recipe overwrote my config," and "my pipeline went red after the level change." Both are mitigable by making the diff-and-reconcile step a documented, mandatory part of the upgrade runbook rather than an optional caution. docs/rules.md is now the effective contract for what Smart App checks; it should be linked from the internal runbook so engineers self-serve on rule semantics, the new info status, and why a given finding is advisory versus blocking.

Scaling: Scales well in breadth — one recipe applied N times — but the recipe model means N independent copies. The leverage point is the shared template repository: fix there once, and the fleet inherits. Fleet-wide, the level-10 move is the scaling hazard: expect a one-time spike in findings proportional to fleet size, and sequence the rollout so the team is not triaging N repos' baselines simultaneously.

Failure modes to watch:

• Silent config loss from --reset --force clobbering custom phpstan.neon / qualimetry.mk — highest-likelihood, highest-impact.
• Strictness inversion: a repo whose phpstan.neon carried a low level now runs at a different effective level than its CI history assumed, either red-lining CI or quietly weakening a gate that previously passed --level=10.
• Rule/reality mismatch: direct --level invocations in CI or IDE configs are invisible to the phpstan.level rule, producing compliance reports that do not reflect actual strictness.
• .env-dependent rule in CI: infra.mysql-version may be blind or noisy where configuration arrives as environment variables rather than a .env file.
• Baseline inflation: a level bump converted straight into phpstan.baseline entries converts a real gate into a large info figure, i.e. the gate looks green while the debt grows — track the baseline count as an explicit metric so the info status does not become a hiding place.
• Semver surprise: patch-numbered releases changing effective gate behaviour make automated dependency bumps unsafe; consider pinning the bundle and upgrading deliberately rather than on a bot PR.

Ramp-up: Minimal for engineers — no new runtime API, no new framework concepts. The learning is procedural, not conceptual: (a) upgrade via diff-and-reconcile, not blind force; (b) the PHPStan level lives in phpstan.neon, not on the command line; (c) info findings are reported debt, not failures. A one-page runbook plus the template-repo change is sufficient onboarding; the work lands mostly on whoever owns CI and the template repository, not on product engineers.