Laravel Fileable Laravel Package

Product Decisions This Supports

• Build vs. buy for file attachments. This package supplies the polymorphic file-to-model layer (a HasFiles trait plus a File model and relation) that would otherwise be hand-rolled in every project that needs attachments. For a team shipping attachments on 2+ models, adopting it removes roughly a sprint's worth of plumbing and its ongoing maintenance.
• Feature scoping and roadmap. It makes "attach files to anything" a cheap, low-risk line item rather than an epic — useful when scoping media/attachment features (avatars, documents, receipts, cover images) into a release and deciding whether media work blocks other roadmap items.
• Architecture direction. It commits the product to a polymorphic, single-files-table storage shape. That decision affects later reporting, storage-cost modeling, and any future media-library migration, so it's worth an explicit, documented choice rather than a per-developer default.
• Talent and velocity. A small, conventional Laravel package lowers onboarding cost compared with an in-house abstraction. Relevant when weighing delivery speed against long-term ownership.

When to Consider This Package

• Consider it when: you are on Laravel, need simple polymorphic file attachments to one or more Eloquent models, do not need image manipulation, transcoding, or a full media library with metadata/conversions, and are comfortable pinning an exact version of a pre-1.0 dependency.
• When to look elsewhere: requirements include image conversions/thumbnails, multi-disk CDN orchestration, video/audio processing, rich media metadata, tagging, or admin UI. In those cases a full media library (e.g. Spatie's) or a purpose-built internal service is the better bet — swapping later is real work, so make this call up front.
• Version risk — read this before adopting. Release 0.3.0 renames the trait Astrotomic\Fileable\Concerns\Fileable to Astrotomic\Fileable\Concerns\HasFiles. This is a breaking change shipped on a minor version bump (0.2 → 0.3). Two PM-relevant consequences:
  1. Immediate migration cost for any existing consumer: find/replace the use statement and trait reference, plus any instanceof/reflection use. Small, but it touches every model that uses the trait and must be coordinated with a deploy.
  2. Signal about stability. A rename between 0.x minors is within SemVer's stated allowance (0.x has no stability promise), but it confirms the API is still settling. Pin the dependency exactly ("astrotomic/laravel-fileable": "0.3.*" or a lockfile), and budget upgrade work in any plan that spans multiple quarters.
• Otherwise defer if the attachment feature is not on the near-term roadmap — a pre-1.0 dependency is cheap to add later and not worth carrying ahead of need.

How to Pitch It (Stakeholders)

• To executives: A small, single-purpose open-source dependency that gives us "attach files to records" in days instead of weeks. It's free and widely applicable, so the main risk isn't cost — it's maturity. The library is pre-1.0 and just shipped a breaking rename in a minor release, so we pin the version, absorb a one-line change now, and re-evaluate when 1.0 lands.
• To engineering: Standard Laravel package providing a HasFiles trait and polymorphic File relation — no custom storage abstraction to own. 0.3.0 renames the trait from Fileable to HasFiles; migration is a find/replace plus a lockfile bump. Pin the exact version and treat upgrades as scheduled work, not automatic.
• Recommendation: Adopt for simple attachment needs with a pinned version and a documented swap-out point; do not adopt if media conversions, CDNs, or rich media management are in scope — those belong to a dedicated media library.