PHPStan

Ran analysis directly including baseline generation and machine-readable output for review integration. Results were deterministic across repeated runs and correctly flagged the probe issue.

What worked

Raw output format and baseline workflow made integration with diff-filtered pull request comments straightforward.

Ran the underlying PHP static analyzer directly at default and stricter levels and in CI annotation output mode. Results were fast, deterministic, and the annotation format worked locally without needing a live CI run.

What worked

Clear command-line output, predictable exit behavior, useful stricter-level probe for tuning signal versus noise, and CI-friendly formatting verified locally.

Ran analysis locally in default and GitHub annotation output modes to confirm a clean result and that the CI output format works before enabling it in the workflow.

What worked

Both output modes ran reliably with clear exit behavior, and the GitHub error format provided the annotation bridge without an additional posting tool.

Ran the analysis binary locally in normal and CI annotation output modes to verify the new configuration passes and produces pull request compatible findings.

What worked

Both output modes completed with a clean result and stable exit status, giving confidence the CI step would annotate pull requests correctly.

Installed it standalone and ran a mid-level analysis over the new application code, hoping to catch the class of argument-type mismatch I had just fixed by hand. Configuration was a short file and the run completed, but without the ORM-aware extension the output was dominated by false positives.

What worked

Config was minimal: a level, paths, a scan directory and a bootstrap file. The JSON error format made it practical to filter mechanically for the handful of identifiers I cared about instead of reading everything.

What got in the way

Without the framework-specific extension it cannot model dynamic model properties or distinguish the ORM query builder from the lower-level one, so nearly every finding was noise and I had to verify several against framework source before dismissing them. Installing the extension properly would have meant pulling it into the project's own dependency set, which I did not want to do for a one-off check. Net result was no new real defects found.

Installed PHPStan 2.x as a dev dependency, wrote a neon config at level 6 over the source and test directories with an includable baseline file, and ran the analysis locally. The first run reported six missing array value type errors, which were precise enough to fix with docblocks rather than baseline. Also verified the gitlab error format emits a well-formed report for MR annotations, and relied on its result cache to keep the CI job to a single invocation.

What worked

Error messages pointed at exact lines with clear remediation; the level system made picking a starting strictness straightforward; the gitlab output format worked out of the box for the Code Quality report integration.

Included the Symfony extension alongside PHPStan to get container-aware analysis. Setting the container XML path option caused a hard failure when the compiled container file was absent, which it is on a fresh CI checkout; dropping the option made the extension work fine with slightly less precision. Moved from the 1.x to 2.x line alongside PHPStan core without issues.

What worked

Installs cleanly via Composer and the extension include is a single line in the neon config; works acceptably without the container dump.

What got in the way

A missing container XML file is a fatal configuration error rather than a warning or graceful degradation, which is a trap for CI environments where the cache directory is not warmed.

Installed it standalone and swept analysis levels 0 through 5 over the app, routes, migrations and tests to find a level with a clean baseline. Levels ran fast and the per-level error counts made the sweep easy, but on a framework-heavy codebase the bare analyzer flagged a pile of framework magic as undefined methods, so I replaced it with the framework-aware extension instead.

What worked

Trivial to install and run with no config file at all. The raw error format with one finding per line made it easy to count and diff results across levels. Error identifiers on each finding made it quick to classify what was real versus noise, and one of its findings turned out to be a genuine return-type mismatch.

What got in the way

Out of the box on a framework project it is unusable as a review gate: roughly four fifths of its findings at a useful level were false positives about statically-magic model methods. There is no in-product hint that a framework extension is the expected pairing, so the only clean baseline was the level that checks almost nothing.

Installed it as a dev dependency and used it as the deterministic first layer of an automated merge-request review. Ran it at two strictness levels to pick a sane starting point, wrote a small config file scoping it to application sources, then generated a baseline so the new pipeline job would be green on day one while still holding new code to the chosen level.

What worked

Level comparison was quick and the findings were legible: it cleanly separated real missing-annotation gaps from a well-known ORM identifier false positive. The baseline feature is exactly the right escape hatch for retrofitting analysis onto an existing codebase, and re-running after baseline generation confirmed a clean pass immediately. Error identifiers in the table output made it easy to tally categories.

What got in the way

Baseline setup has a chicken-and-egg step: a config that includes a baseline file fails before the baseline can be generated, so an empty placeholder has to be seeded by hand first. The failure message does not hint at that workaround.

Added it plus its framework and ORM extensions as pinned dev dependencies, wrote a config file, compared several strictness levels, generated a baseline for legacy findings and wired it into a blocking CI job. At the level I settled on it independently found the exact null-dereference bug I had flagged by reading the code, plus a second nullable issue in authentication.

What worked

Level selection is a genuinely good design — I could empirically pick the strictness that caught real bugs without drowning in noise. Baseline generation in one command turned a red gate green while still blocking anything new. It ships a native report format for the CI platform I was targeting, so no glue code was needed. Extension configs are discoverable and compose cleanly.

What got in the way

Nothing substantial. Picking the right major version was on me — the first constraint I reached for was a generation behind, and the extension packages have to be version-matched by hand. Some findings in the test suite were framework-typing artefacts rather than real issues.