Laravel Attachment Library Laravel Package

Product Decisions This Supports

• Build vs. buy for file handling. Attaching files to records is undifferentiated infrastructure in nearly every Laravel product — support tickets, CMS pages, product catalogs, user avatars, contracts. This package collapses that into a trait, an Attachment model, and one php artisan attachment-library:install command. The honest comparison is roughly one sprint of schema, polymorphic pivot, upload plumbing, and admin UI wiring versus an afternoon of integration, so the default answer for a non-differentiating capability is adopt, not build.
• Roadmap sequencing for media-adjacent features. The package already ships things teams usually defer: attachment collections, ordering, focal-point cropping, file replacement, preset-based resizing, S3/remote-disk support, and a Glide-backed image route. That means "multiple images per product," "reorderable gallery," "properly cropped thumbnails," and "images on S3/CDN" can be scoped as configuration and UI work rather than new backend projects — a real lever when deciding which of those makes the next quarter.
• Scope of the media story. Note the package is closer to a lightweight media library than a file-attachment table: Glide transforms and preset resizing mean image delivery is in scope, not just storage. That is either a large win (you skip building a thumbnail pipeline) or a reason to stop, depending on whether you already run an image CDN.
• Schema and lifecycle ownership. Adopting it means publishing migrations into your database and owning the semantics the README doesn't define: what happens to an Attachment and its blob when the last owning model is deleted, whether attachments are shared across records, and how orphan cleanup runs. Decide this before adoption — it is cheap as a design decision and expensive as a data-cleanup ticket.
• Prioritization against the incumbent. spatie/laravel-medialibrary is the default in this space with orders of magnitude more adoption. The decision is less "package or nothing" and more "this package's batteries-included image pipeline versus the incumbent's ecosystem"; frame it as a comparison, not a first choice by default.

When to Consider This Package

Consider it when:

• The product is Laravel on Eloquent + Storage, and a polymorphic "files on any model" capability is genuinely wanted — not one bespoke upload field.
• You want image transforms, presets, focal points, and collections out of the box, and nobody on the team is excited about owning a Glide integration.
• Uploads need to land on S3 or another remote disk (supported since v1.2.9 / v1.0.0).
• You are comfortable vendoring or forking: MIT license, shallow coupling (a trait plus a relationship name on your models), so exit cost is low if the package stalls.
• You accept a small, agency-maintained dependency. Van Ons is a real shop shipping steady releases (v1.x with bug-fix and feature cadence), but the adoption signal is thin — 3 stars, 0 dependents — so there is no ecosystem pressure to keep it healthy and no crowd-sourced answers when you hit an edge case.

Look elsewhere when:

• You need compliance-grade file handling: virus scanning, DLP, audit trails, retention policies, signed/time-limited URLs, or per-tenant isolation. None of that is advertised here.
• Scale is the dominant constraint — very high image volume, multi-region delivery, or heavy transform throughput where a managed CDN/image service wins outright.
• You need rich asset management (taxonomy, versions, workflow/approval, rights metadata) — this is an attachment layer, not a DAM.
• The team wants a large community, commercial support, or an SLA. That is not what this is, and buying it for support reasons would be a mistake.
• You are not on Laravel, or your storage layer is deliberately abstracted away from Eloquent.

How to Pitch It (Stakeholders)

For executives: We can ship file and image attachments as a configuration task instead of a build project. The package handles polymorphic attachment of files to any record, image resizing and cropping presets, ordering, galleries, and S3 storage — the parts of a media feature that are tedious, easy to get subtly wrong, and invisible to customers. Cost is integration time, not engineering headcount, and the MIT license means no vendor lock-in: the code is ours to fork, and the coupling to our application is a single trait on a handful of models. The risk we are accepting is maintenance risk, not lock-in risk — small project, few users — and the mitigation is that we could replace it without touching our domain logic. Recommended path: a short timeboxed spike against a real screen before we commit it to a roadmap item.

For engineering: Standard Laravel idioms throughout — Composer, service provider, artisan install publishing migrations and assets, an Attachment Eloquent model, HasAttachments, and a Glide route for delivery. Two design commitments to review before we adopt: attachments are standalone records linked polymorphically, so we own the lifecycle and orphan-cleanup policy; and adopting it publishes schema into our database, so the migration is a commitment we should read, not just run. Recent releases cover S3, collections, ordering, focal points, and file replacement, which maps well to what product is likely to ask for next. Please evaluate against Spatie's medialibrary on adoption and long-term maintenance, and flag anything we would need to add — notably scanning and access control.