Presigned Uploader Bundle Laravel Package

Product Decisions This Supports

• Feature enablement — direct-to-storage uploads. The package provides a client-side upload controller for presigned uploads, letting the browser send files straight to object storage instead of through the app server. This unblocks features that routinely die on post_max_size / max_execution_time: media libraries, document ingestion, attachments, avatars, bulk imports.
• Build vs. buy. A presigned upload flow is deceptively expensive to build: signature issuance, CORS policy, retry/progress UX, controller registration, bundler wiring. Buying gets a working controller for the cost of an integration spike; building is justified only if you need deep customization of the signing policy or the UI.
• Roadmap / risk sequencing. v0.2.1 is a packaging fix (missing package.json and dist/upload_controller.js exports), not a feature release. That tells you the project is pre-1.0 and still shaking out distribution mechanics. Appropriate for a spike, prototype, or a non-critical surface now; not something to hard-depend on for a launch-critical path without an abstraction layer.
• Cost/infra decisions. Offloading upload bandwidth and disk I/O to the bucket measurably reduces app-server sizing and removes the need for large ephemeral storage on web nodes.

When to Consider This Package

• You need browser → bucket uploads and would rather adopt a maintained controller than hand-roll one.
• Adopt v0.2.1 or later, and never pin below it. Prior versions failed the asset build outright whenever the package was listed: The file "@vadage/presigned-uploader-bundle/package.json" could not be found under Webpack Encore, and the same failure under vite-plugin-symfony once the upload controller was enabled. This was a hard blocker, not a cosmetic bug — the fix is what makes evaluation possible at all.
• Look elsewhere if:
  • You need server-side processing in the same request (virus scanning, transcoding, image manipulation) — that requires a post-upload pipeline you'll build yourself regardless.
  • You need chunked/resumable uploads for multi-GB files; confirm the controller supports it before committing.
  • You are not on an Encore / vite-plugin-symfony-style asset pipeline. The fix is specifically about how those loaders resolve the package, so verify the controller actually loads under your bundler (Laravel Vite included) during the spike.
  • You require a mature dependency: pre-1.0 versioning, thin maintainer surface, and a patch-only release history are real procurement concerns.
• Note the integration cost honestly: this ships as a Symfony-style bundle with assets/controllers.json (Stimulus) conventions. In a Laravel codebase, budget for adapting the controller and confirming the asset-pipeline assumptions hold — don't treat it as drop-in.

How to Pitch It (Stakeholders)

To executives: This gives us presigned, direct-to-storage uploads without building the plumbing ourselves — files bypass the app server, so upload-heavy features stop being an infrastructure problem and we stop over-provisioning web nodes for bandwidth and disk. It is pre-1.0, so I'd scope it to a contained surface first and keep the option to swap.

To engineering: v0.2.1 fixes a build-breaking defect — the package now exports package.json and dist/upload_controller.js, so assets/controllers.json loaders can resolve it; previously Encore failed the build as soon as the package was listed, and vite-plugin-symfony failed once the upload controller was enabled. No API or behavior changes, no breaking changes, no deprecations. Pin >=0.2.1. The remaining work is integration, not debugging: verify the Stimulus controller loads under our bundler and wrap the upload path behind an internal interface so a future swap is a one-file change.