- What is alies-dev/psalm-tester used for?
- It is a PHPUnit test harness for running Psalm against .phpt fixtures. You write a small code sample and the expected Psalm output, such as issues or traces, and the package checks that Psalm produces exactly that result. It is intended for testing Psalm plugins, custom stubs, and type-inference behavior, including suites like psalm-plugin-laravel. It is a development dependency, not a runtime Laravel package.
- How do I install alies-dev/psalm-tester in a Laravel project?
- Install it as a development dependency with composer require --dev alies-dev/psalm-tester. Version 0.4.0 requires a compatible Psalm version and composer-runtime-api ^2. Then add a PHPUnit test case that creates PsalmTester and loads your .phpt fixtures via PsalmTest::fromPhptFile(). No Laravel service provider or application bootstrapping is required for the harness itself.
- Does psalm-tester test Laravel applications or Psalm plugins?
- It is not a general-purpose batch runner for analyzing an entire Laravel app directory. Its focus is fixture-as-contract testing for Psalm plugins, stubs, and custom type annotations, where your own type-checking behavior is the product. Laravel teams use it when they maintain a Psalm plugin, such as a Laravel-specific plugin, or custom stubs, not as a replacement for running Psalm across app/ and config/.
- Which Psalm versions does psalm-tester 0.4.0 support?
- Version 0.4.0 requires vimeo/psalm ^6.10 or ^7.0.0-beta16, and it also requires composer-runtime-api ^2. That means teams still on Psalm 5.x cannot adopt 0.4.0 without upgrading Psalm first, which may be a larger project than the harness upgrade. Check the package constraints before adding it to an existing Laravel plugin test suite.
- How do I create a PHPT fixture for a Psalm trace or issue?
- Create a .phpt file with a --FILE-- section containing the PHP code to analyze and an --EXPECT-- section containing the exact Psalm output you expect. For traces, include lines like Trace on line 9: $_list: non-empty-list<1|2>. If you do not want to hardcode line numbers or exact types, use an --EXPECTF-- section with placeholders such as %d and %s.
- How do I run PHPT fixtures from PHPUnit with PsalmTester?
- Add a PHPUnit TestCase, create PsalmTester::create(), and call $this->psalmTester->test(PsalmTest::fromPhptFile($phptFile)) for each fixture. You can use PHPUnit attributes such as #[TestWith] to map fixture paths into test cases. The package discovers and runs fixtures in a batched Psalm invocation rather than starting a new Psalm process per fixture.
- Can I pass different Psalm arguments per test suite or per fixture?
- Yes. You can set defaultArguments when calling PsalmTester::create(), for example to use a custom psalm.xml or add --no-cache. You can also add an --ARGS-- section to an individual .phpt fixture to override arguments for that test. In 0.4.0, withArguments() takes one argument per parameter and does not use shell quoting.
- How do EXPECTF and SKIPIF sections work in psalm-tester fixtures?
- EXPECTF works like PHPT format expectations: it lets you match Psalm output with placeholders instead of hardcoding exact line numbers or type strings. SKIPIF contains a small PHP script that echoes a message starting with skip when the fixture should not run, such as when the PHP version is too old. SKIPIF is a fixture-internal precondition, not a branch or environment policy language; handle CI-only or local-only behavior in CI configuration.
- Is psalm-tester suitable for CI and large fixture suites?
- Yes, for large Psalm plugin fixture suites it is designed around batched execution, a bounded process runner, and isolated cache directories with --no-cache per run. The --filter option narrows execution to selected fixtures, which helps local iteration; the release notes cite 4.6s versus roughly 10s on 758 fixtures for filtered runs. For CI, shard by fixture naming convention across matrix jobs and use withEnv() for environment-specific configuration rather than trying to express branch policy in SKIPIF.
- What alternatives exist and what breaks when upgrading psalm-tester to 0.4.0?
- Alternatives include writing ad-hoc Psalm CLI scripts, using Psalm's own test utilities directly, or running PHPStan or Psalm integration tests without PHPT fixtures; psalm-tester's advantage is structured results and fixture-level expectations. Upgrading to 0.4.0 rejects --EXPECT_EXTERNAL-- and --EXPECTF_EXTERNAL-- fixtures, removes the showProgress parameter from create(), and changes withArguments() to pass one argument per parameter without shell parsing. Grep for external expectations before upgrading and inline them per UPGRADING.md.