srio/rest-upload-bundle
Symfony bundle for handling file uploads over a REST API, offering upload endpoints, configurable storage and validation, and support for multiple files—ideal for adding file-upload capabilities to Symfony applications.
Architecture fit. The most important finding is a framing mismatch: srio/rest-upload-bundle is a Symfony bundle, not a Laravel package. It was built for Symfony 2.x/3.x and depends on Symfony's kernel, dependency-injection compiler passes, event dispatcher, form component, and HttpFoundation. It cannot be installed into a Laravel application in any meaningful way — bundles have no equivalent in Laravel's service-provider model, and the package's extension points assume Symfony's form events and request lifecycle. Any assessment that treats this as a drop-in Laravel dependency is starting from a false premise.
What the package actually offers is a design pattern rather than reusable code: a single REST upload endpoint that accepts multiple payload conventions — multipart/form-data, base64-encoded files embedded in JSON, and chunked/partial uploads (PATCH-based resumption) — with Symfony form integration to bind the resulting file to a domain object. That abstraction is genuinely useful and is the reason the package has any visibility at all.
Integration feasibility. Low. The package has not shipped a release since September 2016, carries 46 stars and zero dependents, and predates Symfony 4's directory restructure, the configureOptions/getBlockPrefix form API changes, and every PHP 8.x release. Composer constraints will almost certainly refuse to resolve against PHP 8+ and Symfony 5/6/7. Even on a Symfony stack, adopting this means forking it and performing a nontrivial modernization pass before writing a line of feature code.
Technical risk. High, and concentrated in the worst possible domain. File upload handling is security-sensitive: MIME-type spoofing, path traversal via client-supplied filenames, decompression and memory-exhaustion attacks (base64-in-JSON inflates payloads ~33% and invites full-payload buffering), and unbounded temp-storage growth from abandoned chunked uploads. An unmaintained package in this area means no security advisories, no CVE response, and no upstream to notify. The zero-dependent count also means no downstream validation — no one else has run this against modern toolchains or production traffic.
Key questions.
Stack fit. On Laravel — the stated context — the answer is unambiguous: do not integrate. Laravel already provides the primitives this bundle wraps. $request->file(), the file/mimes/max validation rules, UploadedFile::storeAs(), and the filesystem abstraction with S3/GCS disks cover the multipart path natively. For the resumable path, mature, actively maintained packages exist (pion/laravel-chunk-upload, or a TUS-protocol implementation) that were designed for PHP 8 and current Laravel. For base64-in-JSON, a small custom request class plus a streaming decoder is a few dozen lines and gives you full control over size limits and memory behavior. On Symfony, prefer OneupUploaderBundle or VichUploaderBundle for file-to-entity mapping and a TUS implementation for resumption; there is no reason to resurrect a 2016 bundle.
Migration path. Treat this as greenfield reimplementation against an extracted contract, not a port. The bundle's README and test suite are the valuable artifacts: read them to recover the request/response shapes, the content-type negotiation rules, and the chunk-assembly semantics, then reimplement those contracts in native framework code. This yields a smaller surface area, no inherited BC debt, and code your team actually understands.
Compatibility. Nothing about the package's dependency graph is compatible with a modern runtime. Even the "just use it standalone" fallback fails, because the Symfony form types and DI extension are the substance of the package — strip those and what remains is a thin, easily reproduced HTTP layer.
Sequencing.
Maintenance. The package is de facto abandoned. Adopting it, even via fork, transfers the full maintenance burden: PHP 8 compatibility, Symfony BC breaks, Composer constraint widening, and test-suite repair — all before any feature work. Owning a fork of an upload library means owning its security posture permanently, with no upstream to lean on.
Support. No vendor, no maintainer activity for roughly nine years, no security advisory channel, and a community small enough that issue triage is effectively self-service. Escalation paths are internal only.
Scaling. The base64 path does not scale: JSON-wrapped file payloads inflate bandwidth and force full-body buffering unless you invest in a streaming parser, and they interact badly with typical request-body size limits. The chunked path scales better but introduces state — partial files, session records, assembly logic — that must be garbage-collected and made concurrency-safe. Neither concern is addressed by a 2016 codebase operating against a 2016 storage landscape.
Failure modes. Expect: orphaned temp chunks consuming disk until a sweeper exists; partially completed uploads that never finalize and hold sessions open; memory exhaustion from large base64 decodes; MIME-type spoofing where validation trusts the client-supplied content type; filename collisions or traversal if client names reach the filesystem; and silent corruption where chunk order or checksums are not verified. On a modern PHP runtime, add outright runtime fatals from removed APIs before any of these are reachable.
Ramp-up. Reading the bundle is quick — it is small and the intent is clear. The real cost is the security review and the "we now own this forever" commitment, which dwarfs the initial comprehension effort. The pragmatic recommendation: mine the package for its multi-mode upload API design, credit it as prior art, and build the implementation on current framework primitives with maintained dependencies.
How can I help you explore Laravel packages today?