Laravel Medialibrary Extensions Laravel Package

Product Decisions This Supports

• Build vs. buy for media handling: This package extends Spatie's laravel-medialibrary rather than replacing it, so the decision it informs is usually "extend the existing media layer vs. build custom conversion/responsive-image logic." The 2.8.12 patch (preventing morph map collisions with host application models) is directly relevant to that decision: it lowers the integration risk of layering extensions on top of an app that already registers a morph map — a very common setup for any product with polymorphic media attachments (posts, products, users, pages).
• Roadmap sequencing for media-adjacent features: Supports scoping work on responsive image sets, per-model media collections, conversions, and fallback/placeholder behavior. If the host app relies on Relation::enforceMorphMap() or custom morph aliases (multi-tenant, modular monolith, or package-heavy codebases), this release removes a known class of "works in one module, breaks in another" defects that would otherwise burn sprint capacity during integration.
• Multi-tenant / modular architecture decisions: The collision fix matters most when several parts of the product independently attach media to models. It signals the package is being maintained against real-world polymorphic edge cases, which weighs in favor of adoption for products with growing domain models rather than a single Post model.
• Upgrade/rollout decisions: Low-risk patch; safe to take on a routine dependency bump. No migration, config, or API change implied — so it does not need to be gated behind a feature flag or a dedicated release train.
• Operational risk posture: A steady cadence of small, targeted bug-fix releases (2.8.x) is a favorable maintenance signal for a dependency that sits close to user-facing assets (image URLs, conversions, storage paths), where breakage is highly visible.

When to Consider This Package

Consider adopting when:

• The product already uses spatie/laravel-medialibrary and needs extension behavior (custom conversions, responsive/placeholder handling, path or URL generation tweaks) without forking the upstream package.
• The application registers a morph map, uses polymorphic media across multiple models, or is a modular/multi-tenant codebase where model alias collisions are a realistic failure mode — this is precisely what 2.8.12 hardens.
• You want upstream-style maintenance (semantic versioning, changelog, small fixes) rather than owning bespoke media glue code.
• Media is adjacent to but not core to the product; a maintained extension is cheaper than a dedicated internal library.

Look elsewhere / proceed with caution when:

• The need is fully served by stock laravel-medialibrary — adding an extension layer increases surface area for little gain.
• You require guaranteed long-term support, an SLA, or a large contributor base; this is a small-maintainer package, so treat it as a calculated dependency risk and pin versions.
• The codebase has unusual polymorphic requirements (custom morph maps mutated at runtime, heavy use of morphTo aliasing) — validate with an integration test on the exact Laravel/PHP versions in use before committing.
• You're pre-1.0-style constrained: check Laravel and PHP version support against your matrix; extension packages often trail framework majors.

Before adoption, verify: test coverage of the morph map behavior, compatibility with your Laravel/PHP versions, and whether the extension's overridden classes conflict with any existing customizations or other media-related packages.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, actively maintained open-source add-on for our media/image handling layer rather than building that logic ourselves. The latest release is a routine bug fix that prevents a class of subtle conflicts when several parts of the product attach images to different types of records — the kind of defect that surfaces late, looks like a random broken image, and costs engineering days to trace. Taking this update is low-risk: no migrations, no config changes, no breaking API changes. The strategic value is that it keeps us on a maintained path for media handling instead of accumulating custom code we'd have to own indefinitely; the trade-off is dependence on a small maintainer, which we mitigate by version pinning and an integration test.

For engineering (summary): Patch release 2.8.12 fixes morph map collisions with host application models — relevant if we call Relation::enforceMorphMap() or register aliases that overlap with the package's internal media model aliases. Fix is isolated; no public API, config, or migration changes. Recommended action: bump the dependency, run the media test suite, and add one regression test asserting our morph aliases resolve correctly after the upgrade. If we don't use a morph map, the update is still safe but has no observable effect for us.

Decision requested: Approve the dependency bump and a small regression test; no further roadmap impact.