File System Bundle Laravel Package

Product Decisions This Supports

• Large-file feature scoping. The package's one real claim — moving a 2 GB file inside a PHP process capped at 128 MB — is a direct input to whether uploads, exports, media delivery, or backup/restore can ship on current worker sizing. That's an infrastructure cost line, not an implementation footnote.
• Build vs. buy on the storage abstraction layer. If we need a single interface over local disk and object storage, this is a candidate "buy" — but only for a Symfony codebase. The real decision is "adopt the streaming-by-default pattern," not the package.
• Roadmap sequencing for file endpoints. Any endpoint that proxies bytes through PHP (signed downloads, exports, document preview) forces a stream-vs-buffer decision. Choosing stream-first now avoids a re-architecture when file sizes grow.
• Use-case triage. Strong fit: user media, large CSV/archive exports, anything where we must not materialize content. Weak fit: small config assets, and anything that inherently needs bytes in memory (image resizing, virus scanning, text extraction) or can be served straight from a CDN / signed URL.
• Vendor and platform risk. 12 stars, 0 dependents, a 0.28 score, and a Symfony 2-era bundle shape are decision inputs in themselves. Critically: this is not a Laravel package. It ships no service provider, facade, or publishable config — Laravel's Storage facade (Flysystem) already provides the streaming semantics it advertises. For a Laravel roadmap the honest conclusion is: do not adopt; borrow the constraint.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is a legacy Symfony 2/3 app already wired for bundles, and migrating to Flysystem is a project we don't want to fund right now.
• We have a hard, non-negotiable PHP memory limit (e.g., 128 MB) and a genuine requirement to move 1–2 GB files through application code.
• The use case is stream-shaped — pass-through transfer, copy, checksum, move — not "load, transform, return."
• We accept that we will own and maintain this code indefinitely; upstream is effectively dormant.

Look elsewhere when:

• The stack is Laravel. Use Storage / Flysystem — maintained, first-party-adjacent, with broad adapter coverage and readStream / writeStream / streamDownload already covering the memory-bound case.
• We need cloud backends, multipart uploads, retries, or presigned URLs. A 12-star bundle with zero dependents will not carry that.
• We need PHP 8+ support, security patches, or a CVE response path. Zero dependents means zero downstream pressure to fix anything.
• The requirement is actually "serve large files fast." The right answer is usually to bypass PHP with signed object-store URLs or a CDN, not to make PHP streaming more efficient.
• The team is small. A bespoke abstraction is a permanent onboarding tax on every future engineer who wonders why Storage isn't being used.

How to Pitch It (Stakeholders)

To executives: We evaluated a library that lets PHP move very large files without exhausting server memory — a 2 GB file inside a 128 MB process. The capability is real and worth holding as a standard. The library itself is a low-adoption Symfony component with no downstream users, no maintenance signal, and it does not fit our Laravel stack. Recommendation: do not add it as a dependency; adopt the constraint it demonstrates. Tooling we already have (Laravel Storage / Flysystem) covers the same ground with an active maintenance and security story. Net effect: we get the memory efficiency without unmaintained code or a second storage abstraction.

To engineering: Treat this repo as a design reference, not a dependency. The transferable rule: file operations must be stream-based — never accept or return a fully materialized $content string. Enforce it in code review and in our upload/download helpers. The portable asset is the adapter contract (path-in, handle-out) and the memory-flat benchmark, not the Symfony wiring; installation would collide on symfony/* constraints, PSR-0 autoloading, PHP 5.x idioms, and a stale AWS SDK. If we later find a concrete case where Storage::writeStream can't stay inside our memory budget, this bundle's adapter design is a useful starting point — but we write and own that code. Before mirroring any API surface, confirm it still matches the PHP version we run.