What do PHPStan's Bleeding Edge and the phpstan-strict-rules extension each add beyond rule levels, and how do you enable them?

## Two ways to go past the levels Rule levels 0 to 10 are PHPStan's main strictness dial, but they are not the only one. Two opt-in additions can be used at **any** level: | | Bleeding Edge | phpstan-strict-rules | |---|---|---| | What it is | feature toggles shipped inside PHPStan itself | a separate Composer package | | Purpose | preview of the next major version's rules and behaviour | extra, opinionated rules for defensive code | | Enable | `includes: - phar://phpstan.phar/conf/bleedingEdge.neon` | `composer require --dev phpstan/phpstan-strict-rules`, then installer or manual include | | Changes over time | yes, toggles are added in minor releases | with the extension's own releases | | Becomes default | at the next major version | never; always opt-in | ## Bleeding Edge PHPStan's backward-compatibility promise says a minor or patch release does not look for new categories of errors: new rules arrive only in major versions, and also in Bleeding Edge. They are developed behind **feature toggles** that are switched off by default. `conf/bleedingEdge.neon` sets those toggles to `true`, for example `bleedingEdge: true`, `checkPrintfParameterTypes`, `reportTooWideBool`, `unnecessaryNullCoalesce` in 2.2. - **Enable** it by adding `phar://phpstan.phar/conf/bleedingEdge.neon` to `includes` in `phpstan.neon`. - **Benefit**: new rules and bug fixes reach you months before the next major, and when that major ships most of its new errors are already fixed in your code. - **Cost**: a minor PHPStan update can add errors to a Bleeding Edge build, because new toggles can arrive in minor releases. Teams that want predictable builds pin the PHPStan version and update deliberately. - **Upgrade path**: the 2.0 upgrade guide recommended reaching a green build on the latest 1.12 with Bleeding Edge and `phpstan-deprecation-rules` enabled, then bumping to `^2.0`. For example, 2.0 made "always true" conditions always reported, which in 1.x only phpstan-strict-rules did. ## phpstan-strict-rules `phpstan/phpstan-strict-rules` is an official extension for teams that want extremely defensive, strongly typed code. It works in two ways: 1. It **adds rules** of its own, which PHPStan's rule-levels page describes as revolving around strictly and strongly typed code with no loose casting. 2. It **flips config defaults** documented in PHPStan's config reference, such as: - `polluteScopeWithLoopInitialAssignments`, `polluteScopeWithAlwaysIterableForeach` and `polluteScopeWithBlock` to `false`, so variables set only inside a loop header or a block cannot be read afterwards; - `checkFunctionNameCase` and `checkInternalClassCaseSensitivity` to `true`, reporting `STRLEN()` or `datetime` spelled in the wrong case; - `reportMaybesInMethodSignatures`, `reportMaybesInPropertyPhpDocTypes` and `reportStaticMethodSignatures` to `true`, reporting partial variance violations rather than only complete ones. Because it is opinionated, some rules may not fit a codebase. That is why the enabling mechanism matters. ## Enabling extensions: installer or includes - **`phpstan/extension-installer`** is a Composer plugin. Each installed extension declares its config files in its `composer.json` `extra` section; the plugin generates a class listing them, and PHPStan includes them automatically at startup. `composer require --dev phpstan/extension-installer phpstan/phpstan-strict-rules` is then all you need. - The installer **always enables all of an extension's functionality**. To use only part of strict-rules, or only `extension.neon` but not `rules.neon` from a framework extension, skip the installer and include the chosen files by hand. - Do not do both: if a file is included manually and by the installer, PHPStan stops with a *files are included multiple times* error and tells you to remove the manual include. ## Seeing what you are opting into Because Bleeding Edge is just a NEON file, you can read exactly what it turns on: every toggle is listed in `conf/bleedingEdge.neon` in PHPStan's source, and new toggles are mentioned in the release notes. In 2.2 the list includes toggles such as `checkPrintfParameterTypes`, `reportTooWideBool`, `unnecessaryNullCoalesce` and `checkImportedClassNameCase`. Reading the diff of that file between two PHPStan versions tells you what a Bleeding Edge build will newly report after an upgrade. strict-rules is equally inspectable: its effect on configuration is documented option by option in PHPStan's config reference, where each affected key notes "strict-rules sets it to" the stricter value. PHPStan's baseline documentation also suggests enabling strict-rules together with a baseline, so its rules apply to new code without first fixing every existing violation. ## Choosing and rolling out - Turn on **Bleeding Edge** early on a healthy codebase; it is the cheapest way to make the next major upgrade uneventful. - Add **strict-rules** after the level you target is green, and review its errors as a team, because some of them encode style decisions rather than bugs. - Both can be adopted gradually with the same tools used for raising levels, and neither replaces moving up the numbered levels.