Laravel Fileable Laravel Package

Product Decisions This Supports

• Build vs. buy for file/media handling. Uploading, storing, transforming, and attaching files to models is a recurring feature across almost every product surface (avatars, attachments, galleries, documents). This package is a candidate to standardize that instead of rebuilding per team or per feature, which shortens delivery time for any roadmap item with an upload in it.
• Storage cost and architecture decisions. Release 3.0.0 adds per-collection disk configuration (collection.*.disk), which means a team can route public marketing images to a CDN-backed bucket while keeping sensitive documents on private/local storage — a decision that previously would have required custom code. This directly supports cost-optimization and data-residency conversations.
• Framework upgrade planning. Laravel 13.x support plus a hard drop of Laravel <12.x makes this a forcing function: it aligns the package with the current framework lifecycle, but it also means any product still on Laravel 10/11 cannot take this version. That is a roadmap dependency to surface early, not a detail to discover mid-sprint.
• Technical debt and migration scoping. The namespace change from ToneflixCode\LaravelFileable to Toneflix\LaravelFileable is a breaking rename. If already adopted, this becomes a planned maintenance item (imports, config, service provider, facade aliases); if not yet adopted, it becomes a reason to confirm the package's naming stability before committing.
• Vendor and dependency risk. A namespace reparent from toneflix-code to toneflix is a governance signal — worth confirming who maintains it, release cadence, and issue responsiveness before making it a load-bearing dependency in a customer-facing path.

When to Consider This Package

Consider it when:

• The product needs model-attached file handling (one-to-many or polymorphic media) and the team would otherwise write the same upload/store/serve logic again.
• The team is on Laravel 12.x or 13.x, or has a committed upgrade path to those versions within the planning horizon.
• Multiple media types need different storage targets — the new per-collection disk config removes a class of custom workarounds.
• The team wants a small, purpose-fit dependency rather than a heavier media library or a managed DAM/SaaS.
• There is appetite to own the upgrade: breaking namespace changes should be absorbed by one owner with a migration checklist, not spread ad hoc across squads.

Look elsewhere when:

• The product is on Laravel 11 or earlier and an upgrade is not funded — 3.0.0 is a hard cutoff at <12.x.
• Requirements go beyond fileable attachments: image transformation pipelines, video transcoding, CDN invalidation, signed URL workflows, or asset governance at scale are better served by a dedicated media service.
• Compliance posture demands vendor due diligence that a small, single-maintainer package cannot satisfy (SOC 2 evidence, security review artifacts, guaranteed response SLAs).
• The codebase already has a stable in-house media layer — migration cost would exceed the benefit, especially given the namespace churn.

How to Pitch It (Stakeholders)

To executives: This is a small, focused dependency that converts "file uploads" from a recurring engineering cost into a solved, configurable problem. The new version keeps us aligned with current Laravel and gives us per-collection storage routing, which has a direct cost angle — we can put cheap public assets on object storage and keep sensitive files private without extra engineering. The trade-off is a breaking namespace change in 3.0.0, so this is a scoped, scheduled upgrade, not a drive-by.

To engineering: Adoption is low-effort on Laravel 12/13 and blocked below that. Plan a single migration window covering the ToneflixCode\LaravelFileable → Toneflix\LaravelFileable rename across imports, service provider registration, facade aliases, config, and any routes or events referenced by name. The per-collection disk config is additive and can be adopted incrementally per media type. Pin the version, verify tests after the rename, and assign one owner so the change does not fan out across teams.

Recommendation: Adopt on Laravel 12/13 with a scoped upgrade task and one named owner; treat the namespace change as a maintenance line item, not a blocker; reassess if storage or media-processing requirements grow beyond attachments.