Psalm Laravel Nova Laravel Package

Product Decisions This Supports

• Whether the Nova admin surface gets static analysis at all. Nova's API is fluent, macro-heavy and largely invisible to Psalm (fields, filters, actions, lenses, metrics, tools). Without stubs, the realistic options are: exclude Nova from analysis, maintain a large baseline, or sprinkle @psalm-suppress everywhere. This plugin is the cheap path to actually type-checking that code.
• Build vs. buy vs. suppress. Three viable routes: adopt this package, hand-roll your own Nova stubs (a few hundred lines that decay with every Nova major), or baseline/exclude. The package is effectively a pre-built version of option two — so the decision is really "do we pay maintenance on stubs ourselves, or inherit someone else's?" v0.2.3 is a data point for that question: two real typing bugs in common Nova idioms were found and fixed by the maintainer within the existing release line, which is the behaviour you'd want from an inherited stub set.
• Quality-gate roadmap. If you're planning to raise Psalm's error level or enforce "no new errors" in CI, Nova code is usually the single largest blocker. This determines whether that milestone is a sprint or a quarter. The v0.2.3 fixes target two of the highest-frequency callback signatures in real Nova code (canSee() closures receiving a NovaRequest, and Field::make() resolve callbacks returning typed resources/attributes), so the measured pre-adoption error delta is likely smaller than it would have been on v0.2.2.
• Developer velocity and onboarding. Typed Nova resources mean IDE completion and catching field/method typos in CI rather than as a blank admin panel in staging.
• Risk-register input. A small, zero-dependent, single-organization package is a bus-factor and supply-chain line item, not an infrastructure commitment. It belongs in the dependency review, not the platform strategy. The cadence here — a targeted fix release plus bot-driven dependency hygiene, no API or stub-removal churn — is mildly reassuring but does not change the structural single-maintainer risk.

When to Consider This Package

Adopt when:

• You run Psalm (not PHPStan) in CI and use Laravel Nova — verify the plugin supports your Nova major and Psalm version before anything else. Pin to v0.2.3 or later; the canSee() and Field::make() callback fixes remove false positives that would otherwise land in your baseline.
• Nova is a material share of the codebase — custom tools, cards, fields, filters and actions — not a handful of generated resources.
• You already carry a suppression-heavy baseline around Nova and want to shrink it. Pay particular attention to suppressions attached to canSee()/authorization callbacks and field resolve closures — v0.2.3 may make those redundant.
• You want to tighten Psalm's strictness without drowning in Nova false positives.

Look elsewhere when:

• You use PHPStan. This package does nothing for you; the Larastan/phpstan-laravel ecosystem is far larger and better maintained. This is the most common disqualifier.
• Nova is thin or low-risk — the ROI is near zero; baseline it and move on.
• You're on a Nova version newer than the plugin's last verified support. A stale stub set produces false confidence, which is worse than no analysis.
• You need vendor support, an SLA, or a security-response commitment. Patch releases here are typings fixes, not a support guarantee.
• You're migrating off Nova, or off Psalm.

Evaluation recipe: pin the package, run it against one branch, and compare error counts and false-positive rate before and after. Re-run the same branch against v0.2.2 if you want to see how much of the remaining baseline is stub-coverage rather than genuine type error — the callback-typing fixes in v0.2.3 give a useful signal about whether the maintainer is keeping pace with real-world Nova usage. If the delta is small, write only the stubs you actually need and skip the dependency.

How to Pitch It (Stakeholders)

To executives: It's a free, MIT-licensed static-analysis plugin that closes a quality blind spot in our admin panel — the surface our support and ops teams live in every day, and typically the least type-checked part of the app. Cost is one dependency plus a few hours of setup; the alternative is either unanalyzed Nova code or bespoke stubs we build and maintain ourselves. The latest patch release is maintenance-grade: it fixes incorrect typings for two common Nova callback patterns and updates CI dependencies, with no breaking changes and no new surface area, so it de-risks adoption rather than changing the commercial case.

To engineering: It teaches Psalm Nova's dynamic API surface so field, filter and action calls type-check instead of generating false positives, which lets us raise the error level and stop suppressing Nova wholesale. v0.2.3 corrects two of the noisiest false-positive sources — canSee() callbacks that type-hint NovaRequest, and Field::make() resolve callbacks returning typed resources or attributes — so expect a cleaner result from the evaluation spike than earlier versions would have given. The honest caveat is unchanged: this is a tiny, zero-dependent package from a single maintainer organization. Treat it as a forkable stub set, not a vendor — pin it, review it on every Nova upgrade, and assume we may need to patch or replace it. Recommended next step: a one-day spike on a branch to measure the error delta, then a go/no-go between adopt, hand-roll, and exclude.