Psalm Plugin Stringf Laravel Package

Product Decisions This Supports

• Static-analysis investment level: Whether to raise Psalm to a stricter error level (level 3 or higher) on a codebase where sprintf/printf/sscanf appear frequently. This plugin is the difference between "Psalm understands our format strings" and "Psalm gives up and treats them as mixed," so it directly gates how much type-safety signal we actually get from the tooling we already pay for.
• Build vs. buy for internal DX tooling: If format-string bugs are a recurring defect class, the choice is (a) adopt this plugin, (b) write and maintain an in-house Psalm plugin, or (c) refactor toward typed wrappers around sprintf. This package is the cheap option in that trade-off and should be priced accordingly — small adoption cost, low strategic value, plausible abandonment.
• Runtime-error budget in PHP 8: sprintf/printf with a mismatched placeholder count throws ArgumentCountError/ValueError at runtime, not at compile time. Catching this in CI moves a class of production incidents into pull-request feedback — a measurable reliability decision, not a style preference.
• Code-pattern policy: Whether to tolerate heavy sprintf usage in logging, i18n/translation layers, SQL fragment construction, and templating. If we decide those patterns are staying, tooling support becomes a roadmap item; if we're migrating off them, this package is a stopgap, not a commitment.
• Use cases worth scoping: legacy localization layers with hundreds of format strings; logging pipelines where a bad placeholder silently corrupts an alert; sscanf-based parsers (importers, log scrapers) where a format/type drift produces wrong values rather than an exception — the most expensive failure mode to debug.
• Tooling consolidation: whether Psalm is a long-term part of the stack at all. Adopting a plugin for a static analyzer is a soft commitment to that analyzer; if PHPStan is the likely consolidation target, this package should not enter the dependency graph.

When to Consider This Package

Consider it when all of the following hold:

• The team already runs Psalm in CI on every merge — not as an optional local tool. A plugin for an unused analyzer has zero value.
• The codebase has material sprintf/printf/sscanf/fscanf usage — i18n catalogues, log formatters, CLI output, fixed-width or delimited parsers. Below a few dozen call sites, the payoff is negligible.
• Psalm is configured at a level where format-string mismatches are actually reported, and the team is prepared to fix the findings rather than baseline them into oblivion.
• The package is treated as an optional dev dependency with a pinned version, forkable in an afternoon if maintenance stops.

Look elsewhere when:

• PHPStan is the house analyzer, now or on the roadmap. This is a Psalm-only plugin and offers no PHPStan equivalent; adopting it creates a second analyzer to maintain.
• License hygiene is enforced automatically. The license resolves to NOASSERTION — no SPDX identifier — which will fail most dependency-approval pipelines and requires a human legal read. For a dev-only tool the blast radius is small, but the process cost is real and it should be decided explicitly, not discovered in an audit.
• The codebase targets newer PHP than the plugin has been validated against. Last release was December 2022; assume no PHP 8.3/8.4 hardening and test before relying on it.
• There is no owner for static analysis. A 12-star, single-maintainer, stale package is fine for a team that will patch it; it is a liability for a team that will file a ticket and wait.
• You need guarantees, not diagnostics. This plugin improves inference; it does not enforce formatting conventions. Pair it with coding standards if the goal is consistency rather than correctness.

Practical adoption note: treat it as a spike, not a rollout — one engineer, one sprint, measure findings caught versus noise generated, and decide on evidence. Budget for a possible fork.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, free add-on to a code-quality tool our engineers already run. It teaches that tool to understand PHP's format-string functions, so mistakes like a log line with three placeholders and two arguments — which currently crash at runtime in production — get caught in code review instead. Cost is a few hours of engineering time and no runtime dependency. The caveats are honest: the project is a 12-star community package from 2022 with an unclear license, so we should treat it as a tactical improvement we may need to maintain ourselves, not a platform investment. Recommend a one-sprint, one-engineer evaluation with a go/no-go based on defects caught, and no commitment beyond that.

For engineering leadership: Low-effort, low-risk win on correctness for format-string-heavy code, contingent on Psalm being a real part of our CI (not shelfware). It is a dev dependency — zero production footprint, zero deployment risk, trivially removable. The maintenance risk is genuine but bounded: the plugin is small enough to vendor or reimplement, and pinning the version caps the downside. Do not adopt it as a reason to keep Psalm if tooling consolidation is already on the table; adopt it because Psalm is staying and is currently blind to a defect class.

For the engineering team: Pin the version, run it on one service first, and count signal versus noise before widening. If the license question blocks the dependency pipeline, escalate early rather than working around it — that is a policy call, not an engineering one. If the package proves useful and stale, we own a fork; plan for that possibility up front instead of discovering it during a PHP upgrade.