- How do I install ralphjsmit/pest-plugin-filesystem in a Laravel project?
- Install it as a development dependency with composer require --dev ralphjsmit/pest-plugin-filesystem. The pest-plugin- naming convention implies Pest auto-discovery, so you should not need to register a service provider manually. Keep it in require-dev because it is test tooling only and has no runtime role in your application.
- Does pest-plugin-filesystem support Pest 3, PHPUnit 10 or 11, and Laravel 11 or 12?
- Treat this as the main adoption gate. The last release noted in the evaluation is 1.2.0 from February 2023, and the only Laravel-specific signal is a Laravel 10 support note. Pest 3, PHPUnit 10 and 11, and Laravel 11 and 12 all shipped after that date, so the declared constraints may not resolve against a modern lockfile. Run composer require --dev and check the resolution result before planning any usage.
- Can I use this package if my test suite is PHPUnit-only and does not use Pest?
- No. The package layers filesystem expectations onto Pest's expect() API, so a PHPUnit-only suite gets no value from it. You would need to convert the relevant tests to Pest or use native PHP assertions instead. Do not add it as a general PHPUnit helper.
- Is this a replacement for Laravel Storage::fake() and fake disks?
- No, and the distinction matters. These helpers are described as filesystem testing helpers that verify real files and directories, whereas Storage::fake() swaps in a temporary Flysystem disk. If your code writes through Laravel's Storage facade, assert against the fake disk with Laravel's own helpers. Use this plugin only where your test targets local filesystem paths directly, otherwise you risk duplicating or missing assertions.
- How does the file contains assertion work: substring matching or line-based matching?
- Confirm this in the package source before relying on it, because the evaluation flags assertion semantics as the highest-impact correctness risk. A helper that checks for a substring can pass when you expected an exact line, and that can hide a real regression. Write explicit negative tests, such as a file that should not contain the value, and do not assume line-based behaviour.
- Are the filesystem helpers safe to use with Pest parallel testing or Paratest?
- That is not established by the available context, so treat it as unproven. Any helper that creates temporary files or directories must use unique paths per process and clean up on failure as well as success. Until you verify that behaviour, keep filesystem assertions in non-parallel test files or use your own unique temporary directories.
- Is ralphjsmit/pest-plugin-filesystem still maintained, and how risky is the stale release date?
- The last release is February 2023, so maintenance activity is a legitimate concern. The mitigating factor is that the functional surface is thin wrappers over native filesystem calls, which caps the risk. The larger issue is version lock-out against newer Pest and PHPUnit majors, not a complex runtime failure.
- What are the alternatives if the plugin does not install with my Pest version?
- Reimplement the assertions you actually need as expect()->extend() calls in tests/Pest.php. The evaluation estimates that at roughly 30 to 100 lines for the common cases such as file exists, directory exists, contents match, and path missing. That keeps you on current Pest and removes the third-party dependency entirely.
- Does this package add any production runtime dependencies or service providers?
- No. It is intended as a development-only test dependency with no service provider on the request path, no migrations, and no storage driver. That means no impact on production latency, deployment, or runtime configuration. The only place it executes is your test suite and CI.
- What should I review before trusting this plugin in CI?
- Review the source and pin the version, because dev dependencies still execute in CI with access to repository secrets. Check the package's own test coverage and CI matrix, since a test helper with untested helpers is a legitimate blocker. Deliberately test negative cases and run composer audit over dev dependencies, then decide whether the convenience is worth the maintenance overhead.