Weave Code
File System Bundle Laravel Package
kitpages/file-system-bundle
Kitpages FileSystemBundle is a Symfony bundle for working with files and directories through reusable filesystem services and helpers, simplifying common storage and file-management tasks in your applications.
This is a bundle that provides a filesystem abstraction layer. Basicaly this does the same as the gaufrette library from KnpLabs, but it manages much more efficiently big files. We can manage a 2GB file with a memory limit of 128Mo for the PHP process. We never transfert the entire content in a $content variable.
Frequently asked questions about File System Bundle
- Is kitpages/file-system-bundle compatible with Laravel?
- No. It is a Symfony 2-era bundle that registers itself through services.xml and Symfony's DI container, optionally with the EventDispatcher. Composer will autoload its classes into a Laravel app, but nothing gets bound into Laravel's container because there is no ServiceProvider, no facade, and no publishable config. Every adapter would require a hand-written bridge.
- What does KitpagesFileSystemBundle actually do?
- It provides a lightweight abstraction for managing files and directories through reusable filesystem services, with configurable storage paths and a focused API for common file operations. The goal is to keep filesystem logic out of controllers and make storage consistent across a Symfony application. It is a thin layer, not a full storage engine.
- Can I install kitpages/file-system-bundle in a Laravel 10 or 11 project?
- Direct installation is low feasibility. Expect pinned symfony/* ~2.x constraints that conflict with the Symfony 6/7 components Laravel ships, PSR-0 or early PSR-4 autoloading, and PHP 5.3 to 5.6 idioms. The documented setup path uses AppKernel.php bundle registration, which is itself evidence of the stack mismatch. If you want to inspect it, do so in a throwaway Symfony app, not your Laravel codebase.
- Does it support PHP 8 and modern Laravel versions?
- There is no PHP 8 compatibility, no security triage, and no recent releases — roughly a decade with none. The codebase predates modern type declarations and contemporary PSR standards. Treat it as legacy Symfony 2 code, not a maintained PHP package.
- What is the Laravel native alternative to this bundle?
- Laravel's Storage facade, which wraps Flysystem, is the idiomatic home for this problem and is already bound into the container. Local moves can use stream_copy_to_stream between handles to keep memory flat, and S3 work can use Storage::writeStream with multipart uploads or, better, presigned PUT/GET URLs that bypass the PHP process entirely. The bundle's differentiator is achievable natively on a maintained dependency, so do not add a second storage abstraction alongside Storage.
- Is the streaming design pattern worth extracting?
- Yes. The genuinely portable asset is a thin adapter contract where the content argument is a file path or stream handle rather than a string, so a 2 GB transfer never materializes in a PHP variable. Define your own PHP 8 FileStoreInterface with putStream, getStream, delete, exists, and url, then implement a local adapter using a temp file plus rename() for atomicity and an S3 adapter using multipart uploads. Bind them in a service provider and map config into a dedicated disk definition.
- What are the risks of pulling in its S3 adapter?
- Dependency contagion is the big one. The adapter targets AWS SDK v1 or v2, which carries its own CVE history, and pulling a stale SDK transitively into a modern Laravel app is a larger risk than the bundle itself. There is also no Flysystem interop, so you would end up maintaining two storage paths.
- Does the bundle handle atomic writes, checksum verification, or retries?
- Based on the available information it appears to offer none of these. If you need them, build them yourself: write to a temp file and rename() for atomicity, verify checksums after transfer, and make retries idempotent. These are exactly the behaviors production file pipelines depend on, so plan for them explicitly.
- Can I fork and vendor the package since it is abandoned?
- The MIT license is clean, so forking and vendoring is legally unencumbered. The real constraint is cost, not law: with 12 stars, no dependents, and no releases in about a decade, you would own the fork indefinitely. Decide up front whether you are prepared to maintain it or intend to decommission it within a set number of months.
- How do I test whether streaming actually fixes my memory problem?
- First identify the pain point: upload memory, download memory, or both, because Laravel's readStream and writeStream already cover both. Then run a timeboxed spike in a throwaway app, benchmark a 1 to 2 GB file, and compare memory behavior against your current implementation. Remember that streaming solves the memory ceiling and does nothing for worker occupancy, so measure p50 and p99 file sizes plus peak concurrent transfers per worker pool before assuming streaming is the answer.
Weaver
How can I help you explore Laravel packages today?