Weave Code
Standard Bundle Laravel Package
smartbooster/standard-bundle
SmartBooster Standard Bundle packages reusable Symfony services, helpers, and default configuration into one installable bundle, simplifying project setup and keeping applications consistent. Add it to bootstrap common features faster and cut boilerplate across SmartBooster projects.
Bundle grouping all dev vendor that we use for testing and coding with the SMART BOOSTER standards
Frequently asked questions about Standard Bundle
- What is smartbooster/standard-bundle used for?
- It is a development-tooling bundle that groups all the vendor packages SmartBooster uses for testing and coding standards. It ships Composer recipes that copy config artifacts such as phpstan.neon, make/qualimetry.mk and related docs into the consuming repository, plus a rule catalogue enforced by Smart App. It has no bearing on application runtime, request handling or data paths, so its value is standardising static analysis, taint analysis, code style and CI linting across a repo fleet.
- Is smartbooster/standard-bundle compatible with Laravel?
- It is a Symfony bundle and leans on Symfony tooling and conventions, including symfony.lints and Doctrine DBAL server_version checks, so it is not a Laravel runtime package and ships no service provider. The underlying pieces, PHPStan, Psalm, php-cs-fixer and Make quality targets, are plain PHP tooling that a Laravel team could adapt into its own CI. Treat it as a dev-dependency or a reference implementation for quality gates rather than a drop-in Laravel package.
- How do I install and upgrade smartbooster/standard-bundle?
- Require it as a dev dependency with Composer and let the Symfony Flex recipes copy the config files into your repository. The prescribed upgrade command is composer recipes:install smartbooster/standard-bundle --reset --force, which overwrites phpstan.neon and make/qualimetry.mk unconditionally. Back up or commit those files first, because any project-local customisation is destroyed without warning.
- Why did PHPStan strictness change in v1.8.2?
- In v1.8.2 the PHPStan level moved out of the Makefile and into the shipped phpstan.neon as parameters.level: 10, and make/qualimetry.mk no longer passes --level=10. If your in-file level was lower and you relied on the CLI flag, effective strictness shifts silently in one direction or the other. A level passed on the command line is also not visible to the phpstan.level rule, so direct --level invocations are now scored against the file value.
- How do I deal with the flood of new PHPStan errors after upgrading?
- A jump to level 10 surfaces findings that were previously suppressed, so expect a wave of new errors and plan the upgrade as its own change. The usual path is to regenerate the PHPStan baseline and triage incrementally, remembering that the phpstan.baseline rule reports baseline size as info-level debt. Review the new errors rather than blindly growing ignoreErrors, and check whether the Make targets still honour a LEVEL variable if a team needs a temporary override.
- What does the infra.mysql-version rule check and does it need a .env file?
- The new infra.mysql-version rule reads MYSQL_VERSION from .env and cross-checks it against doctrine.dbal.server_version, with a patch included. Because it depends on a checked-out .env, CI runners that inject configuration as environment variables may produce no finding or a false negative in exactly the environment where it matters. Verify its behaviour in your pipeline before treating it as a gate.
- Does the new info status fail a CI pipeline?
- The info status added alongside the documented code-quality rules is non-blocking and purely advisory debt reporting, so it should not fail a build on its own. Blocking behaviour stays with the error-level rules. Confirm with the owning team whether info can be promoted to blocking per repository if you want it enforced.
- Will recipes:install --reset --force overwrite my custom phpstan.neon?
- Yes. That command overwrites phpstan.neon and make/qualimetry.mk unconditionally, so custom paths, excludePaths, bootstrap files, extension includes, baseline path, ignoreErrors and Makefile target overrides are all lost. Copy your customisations aside, then re-apply them onto the regenerated files, or install without --force and diff the output. There is no documented reconciliation path at v1.8.2, so raise it with the maintainers if you cannot take the overwrite verbatim.
- Which PHP, Symfony, PHPStan and Psalm versions are supported at v1.8.2?
- No clear support matrix is published for v1.8.2, so read the Composer constraints in the repository before adopting. In practice it targets modern PHP with PHPStan at level 10, Psalm taint analysis, php-cs-fixer, Symfony lints and composer-check. Because the shipped config artifacts are tightly coupled to specific PHPStan and Psalm majors, ask the owning team to document supported versions and a changelog contract for config-affecting changes.
- What are the alternatives, and is a patch release changing PHPStan strictness a semver concern?
- Alternatives include maintaining a shared phpstan.neon and php-cs-fixer config in your own internal Composer package, using phpstan/extension-installer, or adding GrumPHP or CaptainHook for hooks and gates; all give you centralised quality config without the recipe overwrite risk. On semver, the package API is unchanged but the effective strictness and the mechanism configuring it did change, which is a minor-or-major-shaped change for consumers even on a patch bump. Raise it with the maintainer and ask whether flag config-affecting releases as at least a minor version.
Weaver
How can I help you explore Laravel packages today?