Weave Code
Psalm Laravel Package
vimeo/psalm
Psalm is a static analysis tool for PHP that finds type errors, bugs, and unsafe code before runtime. It offers configurable strictness, baseline support, and CI integration to help teams catch issues early and improve code quality.
Psalm is a static analysis tool for PHP that scans your codebase without executing it, catching type errors, undefined variables, impossible conditions, and other bugs before they reach production. It builds a detailed understanding of your code's types and flow, then reports issues with precise file and line locations.
- Progressive strictness levels from lenient checks to rigorous type safety
- Rich type inference, including generics, unions, and literal types
- Baseline support to silence existing errors and enforce cleanliness on new code
- Automatic fixes for many detected issues via
--alter - Framework-aware plugins for Laravel, Symfony, Doctrine, and more
Frequently asked questions about Psalm
- How do I install Psalm in a Laravel project?
- Install it as a dev dependency with composer require --dev vimeo/psalm; it is MIT licensed and ships no runtime code. For Laravel-specific understanding, add the community psalm-plugin-laravel package and enable it in your Psalm config. Then run psalm --init to generate a config and pick a starting error level. Keep Psalm in require-dev so production artifacts and the Laravel bootstrap are unaffected.
- Does Psalm understand Laravel facades and Eloquent models?
- Psalm itself is framework-agnostic, so Laravel ergonomics depend on the community psalm-plugin-laravel package. That plugin adds support for facades, Eloquent magic properties, container resolution, and validation. The plugin is the real feasibility gate for Laravel teams, especially with Psalm 7.0.0-rc2 taint changes, so verify compatibility before making it a release-blocking gate.
- What Psalm error level should I use for an existing Laravel codebase?
- Start with psalm --init, which auto-selects an error level matching your current error count, so you get a sane strictness without manual tuning. Then tighten the level over time as you fix issues. For brownfield apps, baselines are the decisive unlock because they let you adopt Psalm without fixing every pre-existing error first.
- How do I run Psalm in GitHub Actions or another CI pipeline for Laravel?
- Psalm is a single CLI invocation and supports machine-readable reporters including text, JSON, checkstyle, GitHub Actions annotations, and SARIF in recent releases. That means it drops into GitHub Actions, GitLab, Jenkins, and Bitbucket without bespoke tooling. Run it as a dev-only CI job and keep the taint analysis baseline separate from the type-analysis baseline if you enable taint mode. It complements PHPUnit/Pest, Rector, Pint, and DAST rather than replacing them.
- Can Psalm catch SQL injection and other security issues in Laravel apps?
- Yes, Psalm has taint analysis for categories such as SQL injection, HTML output, shell injection, SSRF, and headers. Psalm 7.0.0-rc2 widens the model with query injection and path injection kinds, plus new sources like $_SERVER, $_FILES, DNS answers, and exception messages. New sinks include debug output functions and writes to php://output or php://stdout, which maps more completely to OWASP categories. It is static only, so it does not observe runtime data flow and does not replace DAST or runtime APM.
- Should I use Psalm and Larastan/PHPStan together in a Laravel project?
- Psalm and Larastan/PHPStan occupy the same slot, so a tech lead should make an explicit one analysis backbone decision up front. Running both doubles CI cost and triage load and produces overlapping but divergent findings. Pick the one that fits your team, then use the other only if you have a specific gap that justifies the overhead.
- How do I adopt Psalm in a legacy Laravel project with many existing errors?
- Use --set-baseline to record current issues so the CI gate only fails on new errors, which is the decisive unlock for brownfield adoption. Psalm --init also helps by choosing an error level that matches the current error count. If you enable taint analysis, keep a separate taint baseline from the type-analysis baseline because the finding classes churn independently. This lets you ratchet strictness gradually without blocking delivery on day one.
- Does Psalm slow down my Laravel application in production?
- No, Psalm is a dev-time-only dependency installed with composer require --dev, so it ships no runtime code path. It has zero impact on Laravel bootstrap, container resolution, the autoload graph, or production artifact size. The only cost is CI time and developer machine time when you run analysis. That makes architecture review cheap compared with a runtime library.
- Does Psalm provide IDE feedback while I code?
- Yes, Psalm has a language-server mode that provides incremental IDE feedback, which is what actually changes engineer behavior day to day. You still run the full CLI analysis in CI as the release gate. The language server is most useful once your baseline is in place so you see new issues rather than legacy noise.
- Is Psalm actively maintained, and what are the risks of depending on it?
- The README states there is a single active maintainer, Daniil Gentili, who monetizes via direct support contracts; two former maintainers have departed. That bus factor is the top risk if you make Psalm a release-blocking CI gate in a supply-chain sense. Version volatility is another concern because 7.0.0-rc2 is still pre-GA and the taint changeset has grown. Mitigate by pinning versions, tracking plugin compatibility, and keeping an exit plan or support contract.
Weaver
How can I help you explore Laravel packages today?