Storage Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for the storage layer. This package is only a candidate for the "borrow" option: it claims pre-built adapter-based storage abstraction (local disk, object storage, custom drivers, streamed reads/writes) that would otherwise cost 2–6 weeks of commodity plumbing. The PM decision is whether uploads/media/exports are differentiating (build) or plumbing (borrow). Given zero stars, zero dependents, and Bitbucket-only hosting, the honest framing is borrow-with-a-fork, not "adopt a dependency."
• Roadmap sequencing for media-heavy epics. If the next two quarters include user uploads, document attachments, product images, export/archive jobs, or per-tenant file isolation, this determines whether a "storage layer" epic gets staffed now or deferred behind a thin in-house adapter over Laravel's Storage facade. The answer here should be: defer, and let a concrete feature force the decision.
• Architecture standardization. A single storage abstraction can consolidate scattered Storage::disk() calls, ad-hoc path conventions, and hand-rolled signed-URL logic — a maintainability and security win independent of any feature. But Laravel already provides this via Storage + Flysystem; the package only earns its place if it adds multi-tenant disk routing, retention rules, virus-scan hooks, or chunked uploads that the framework does not.
• Framework-alignment decision (the big one). The -bundle naming, *Bundle class, DependencyInjection extensions, and config/bundles.php registration signal a Symfony package, not a Laravel one. For a Laravel product this is a strategic decision about hiring, onboarding, and upgrade paths — not a technical footnote. Adopting it means owning a bridge.
• Total cost of ownership and bus-factor. The PM question is not "is this good code?" but "who patches it when a Laravel/Flysystem upgrade breaks it in production?" Assume we own it from day one: internal fork, named owner, mirrored repo, SHA pin, quarterly "still needed?" review.
• Procurement and legal posture. The repo originates from an eactive internal Bitbucket org. The real gate is confirming source access, license terms permitting fork and redistribution, and whether a support agreement exists. That is a procurement decision that must close before any engineering spike is scheduled.

When to Consider This Package

Consider it only when most of the following hold:

• You are already inside the eactive/Integrated ecosystem — existing services depend on it, or a partner mandates it — so integration patterns and a support path are known rather than guessed.
• You have confirmed read access to the source and can fork it into your own org. Treat the Bitbucket repo as a starting point, never as a dependency you consume blind.
• The work is Symfony-native (or you are prepared to fund a Laravel bridge), matching the *Bundle / DependencyInjection structure the package actually ships.
• Your storage needs are conventional — local disk, S3-compatible object storage, path conventions, temporary URLs, maybe image derivatives — not a differentiated media pipeline.
• You can absorb it into your maintenance budget: assigned owner, pinned commit, mirrored remote, contract tests around upload/download/delete/signed-URL/permissions.
• License terms are confirmed compatible with your distribution model (SaaS usually fine; on-prem or redistributed code often not).

Look elsewhere — or build thin — when:

• You are a standard Laravel app. Illuminate\Support\Facades\Storage over league/flysystem with league/flysystem-aws-s3-v3 covers 80–90% of this in an afternoon, with a large community, active security coverage, and zero bus factor.
• You need CDN edge transforms, virus scanning, resumable/chunked uploads, or per-tenant encryption — evaluate purpose-built services, not a generic bundle.
• Any of these are true: no source access, unclear license, no named maintainer, no tests, no release/tag history, or PHP/Laravel/Flysystem version constraints that conflict with your pins (Laravel 9+ = Flysystem 3; a bundle written against Flysystem 1/2 will fail at the solver).
• You cannot commit an owner. An unmaintained dependency in the storage path is an availability and data-loss risk, not a convenience.
• The package cannot prove a capability beyond the framework. If, on audit, it is a ~200-line wrapper over Flysystem, build the tenant-aware disk configuration in-house and keep full ownership.

Gating checks before any pilot: confirm the target framework and PHP version from composer.json; verify extra.laravel.providers vs. config/bundles.php registration expectations; run a time-boxed spike (install via VCS repository entry, wire one non-critical bucket, upload/download/delete, verify signing and failure behaviour); check for a competing driver name that could shadow production disks; measure transitive dependency weight and memory profile on multi-hundred-MB uploads. Set an explicit exit criterion — if the spike exceeds ~2 days, the borrow case usually loses to a 1-day in-house adapter.

How to Pitch It (Stakeholders)

One-liner for executives: This is a pre-built storage abstraction from an internal PHP ecosystem with no external adoption — no stars, no dependents, no community, no release history. It is a reuse opportunity, not a strategic bet. Recommend a time-boxed spike, not a roadmap commitment, and do not spend roadmap capacity on it until a concrete feature (uploads, media, exports) forces the choice.

For engineering: The upside is skipping commodity plumbing — disk abstraction, path conventions, URL signing, streaming — and inheriting whatever conventions the originating team established. The costs are concrete: it is Bitbucket-hosted and effectively single-source; the -bundle packaging indicates Symfony conventions that would need a Laravel adapter (or a re-scope); and there is no user base to inherit bug fixes or security patches from. We own it the day we adopt it, which means an internal fork, a SHA pin, a mirrored remote so CI does not depend on Bitbucket uptime, and a named owner with a quarterly review.

Recommendation to the group: Default to Laravel's native Storage/Flysystem unless (a) we are already inside that ecosystem, or (b) the spike demonstrably saves meaningful time and we have secured source access plus a named internal owner plus acceptable license terms. Frame the decision as "adopt-with-a-fork-and-an-owner" or "build thin" — never "take a dependency." Keep it off the roadmap until a real feature creates the deadline.

Risk to state plainly: A zero-adoption package in the storage path has failure modes we cannot outsource — silent breakage on framework or Flysystem upgrades, security issues in file uploads / path construction / signed URLs with no upstream patch, cross-tenant path leakage from naive key construction, silent fallback to ephemeral local disk on provider error, and knowledge concentrated in people we may not have. That is an acceptable profile for a two-day experiment behind a feature flag on one bucket. It is not acceptable as an unexamined production dependency.