Flysystem Vfs Laravel Package

Product Decisions This Supports

• Test strategy for file-heavy features. A PM can use this package as a candidate test double for uploads, imports, exports, temp-file pipelines, and storage-service classes. It mounts an in-memory VFS behind Flysystem’s API, so tests can avoid real disk I/O and CI fixture cleanup.
• Build vs. buy for test infrastructure. The real decision is not “should we have an in-memory filesystem for tests?” but “should we adopt this adapter, use Flysystem’s native in-memory adapter, use Laravel’s Storage::fake(), or hand-roll a fake?” This package is the “buy” option at one Composer dependency — but only if it installs cleanly against the current stack.
• Storage abstraction roadmap. Evaluating it forces a useful inventory: which product areas genuinely need a filesystem, and which use one out of convenience? That answer informs whether future work hardens storage abstractions or defers them.
• Legacy modernization decisions. The adapter targets the Flysystem 1.x era. Adopting it in affected code paths means accepting older Flysystem contracts, which should be explicit in any upgrade or migration plan.
• Sandboxed/plugin I/O use cases. For isolated, ephemeral, non-production file operations, an in-memory VFS can be attractive. But the PM should treat this as a narrow test/sandbox capability, not a product storage feature.
• Dependency risk management. With a 2016 last release, 19 stars, zero dependents, and no upstream maintenance signal, adoption is effectively a commitment to own or fork the dependency. That is a product risk decision, not just an engineering preference.

When to Consider This Package

• Only if the codebase is already on Flysystem 1.x and the team wants a virtual filesystem with minimal code change. The adapter implements the older Flysystem adapter contract and is not a drop-in fit for Flysystem 2.x/3.x.
• Only for tests, CI, sandboxing, or ephemeral local workflows. A process-local, in-memory filesystem is not appropriate for production persistence, large files, shared state, or durable storage.
• When the team already accepts michael-donat/php-vfs. This package is a thin bridge; adopting it means inheriting php-vfs behavior, limitations, and maintenance status.
• When the organization is prepared to vendor or fork it. If a legacy application truly depends on it, isolate it behind an internal contract and plan for private ownership.
• Look elsewhere in modern Laravel/PHP stacks. Laravel 9/10/11 ship Flysystem 3.x; use Storage::fake() or the maintained league/flysystem-memory / InMemoryFilesystemAdapter.
• Look elsewhere when behavioral fidelity matters. Permissions, locking, case sensitivity, symlinks, stream wrappers, MIME detection, and large-file behavior will diverge from production disks.
• Look elsewhere when maintenance guarantees are required. No security-response story, no upstream compatibility work, and negligible community adoption make this a poor default dependency.
• Use mikey179/vfsstream instead when the need is a mature, widely adopted virtual filesystem for PHP tests with stronger community support.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, MIT-licensed PHP library that lets file-handling code run against a fake in-memory filesystem during automated testing. The benefit is faster, more isolated tests and fewer CI failures caused by disk state. The catch is that it is effectively unmaintained — last release in 2016 — and it only fits the older Flysystem version used by legacy Laravel applications. Recommendation: do not add it as a new dependency; confirm whether our current stack already provides an official in-memory adapter through Storage::fake() or league/flysystem-memory, which delivers the same testing benefit with far less maintenance risk.

For engineering: This is a thin VfsAdapter bridge between michael-donat/php-vfs and Flysystem 1.x. It is a test double, not a storage engine. Before any adoption, verify the installed Flysystem major version: on Flysystem 2.x/3.x, the adapter contract is different and Composer will likely refuse co-installation. Also assess stream-wrapper lifecycle issues, metadata divergence, memory bounds, and the cost of owning a fork. If a legacy path must use it, wrap it behind an internal VirtualFilesystem contract, pin versions, vendor the dependency, and document that it never touches production code paths.

Decision requested: approve a short evaluation — roughly half a day — to confirm our Flysystem version and compare this package against Laravel’s Storage::fake(), league/flysystem-memory, and mikey179/vfsstream. Default recommendation: use a maintained option; adopt this package only for an isolated legacy Flysystem 1.x case with a named internal owner.