Psalm Laravel Package

Product Decisions This Supports

• Prioritizing technical-debt work with evidence, not anecdotes. Psalm’s issue counts, strictness levels, and baselines give PMs a measurable inventory of type errors, undefined methods, dead code, and unsafe flows. Use this to rank refactor epics, estimate remediation, and define “quality debt” OKRs.
• Release-gating and quality SLOs. Adopt Psalm as a CI gate at a defined level (e.g., start at level 4–6, ratchet upward). This supports decisions like “ship/no-ship,” “can we safely upgrade PHP/framework versions,” and “what defect escape rate are we willing to accept.”
• Security roadmap and compliance evidence. Taint analysis traces user input to sinks such as SQL, HTML output, shell, files, and network calls. As of 7.0.0-rc2 the source/sink model is materially broader: superglobals ($_SERVER, $_FILES, $_SESSION reset semantics), exception messages, closures and callables, generators/iterators, builtin object arguments and return values, DNS answers, and stream writes to php://output/php://stdout. New taint kinds for query injection and path injection map more directly onto OWASP-style risk categories, which makes Psalm output easier to translate into a security backlog and audit evidence.
• Build vs. buy for static analysis. Psalm is MIT-licensed, widely used, and feature-rich. For PHP teams, the default should be “adopt and configure” rather than “build an internal analyzer,” unless requirements are highly proprietary. A support contract is a purchasable risk mitigation rather than a build decision.
• Framework and dependency upgrade decisions. Running Psalm before/after upgrades surfaces type breaks and dead code paths. This supports roadmap calls like “upgrade Laravel/PHP now vs. defer” with concrete issue deltas. The 6.x backports in this release (PHP 8.4 Dom\ API stubs, nullsafe short-circuit modeling, type-alias ordering) directly improve upgrade-signal quality for teams that stay on the stable line.
• QA and code-review capacity planning. Fewer runtime type errors and undefined-method failures mean less QA time on preventable defects. PMs can reallocate QA effort toward exploratory and product-risk testing.
• Use-case fit assessment for AI/automation. Psalter’s automatic fixes and machine-readable reports make Psalm a candidate for automated remediation workflows, but only after triage rules and ownership are defined. Note that much of the 7.0.0-rc2 changelog is taint-precision fixes (false positives and missed flows); expect triage tuning before automating anything on top of taint findings.

When to Consider This Package

Consider Psalm when:

• The product is a PHP codebase, especially Laravel/modern PHP with meaningful type usage, CI, and multiple contributors.
• You need security-focused static analysis (taint tracking) beyond style linting — including injection-class coverage of query, path, SQL, shell, HTML, and I/O flows.
• You want incremental adoption: baselines let legacy codebases start clean and ratchet strictness over time.
• You need CI integration and a quality gate that is cheap to run compared with runtime testing.
• You have engineering ownership to triage findings; static analysis without triage becomes noise.
• You can tolerate an OSS governance model with a single dominant maintainer and optional commercial support.

Look elsewhere or defer when:

• The codebase is not PHP, or is mostly small scripts/throwaway code.
• The team lacks CI discipline or cannot assign ownership for fixing/triaging findings.
• You require a vendor SLA, guaranteed release cadence, or enterprise support out of the box.
• You are already deeply standardized on another analyzer (e.g., PHPStan) and the marginal value does not justify dual-tool overhead; running both can be valid but should be a deliberate pilot.
• You are risk-averse about pre-GA releases: 7.0.0-rc2 is still a release candidate, and its changelog is dominated by taint-engine corrections (flow widening, missing sinks, stale-taint clearing, superglobal/static-property invalidation). Expect finding churn between RCs. Evaluate the stable 6.x line first unless you specifically need the expanded taint coverage or generic @throws/constructor @return typing.

How to Pitch It (Stakeholders)

To executives: Psalm is a low-cost, MIT-licensed static analysis tool that catches PHP defects before runtime, including security-relevant taint flows. The latest 7.0 release candidate meaningfully widens that coverage — injection-class sinks, request superglobals, output streams, and third-party object boundaries — which makes it a stronger input to security prioritization. It gives us a measurable quality/security gate in CI, helps prioritize debt, and reduces preventable QA and incident cost. Main risks: maintainer concentration and the fact that 7.0 is still pre-GA with an actively churning taint engine. Mitigate with a pinned stable version (6.x by default), internal ownership, and an optional support contract.

To engineering: Adopt Psalm incrementally. Start with a baseline so existing issues do not block delivery, gate new code at a fixed level, and ratchet strictness over time. Use CI reports for triage, Psalter for safe autofixes, and plugins/stubs for framework-specific accuracy. If you want the new injection-oriented taint kinds, pilot 7.0.0-rc2 in report-only mode on one service and diff findings against your 6.x baseline before gating on it — treat finding deltas as engine changes, not new regressions.

To security/compliance: Psalm’s taint analysis provides code-level evidence that user-controlled input is tracked to sinks like SQL, HTML, shell, files, network calls, and query/path injection points. It complements pen tests and code review; it does not replace them.

Recommended first step: Run a 2–4 week pilot on one Laravel service: baseline the codebase, add a non-blocking CI report on stable 6.x, measure issue volume and false-positive triage cost, then run a parallel report-only pass on 7.0.0-rc2 to quantify the taint coverage gain. Decide on a blocking gate level only after both data points are in.