Livewire Media Selector Laravel Package

Product Decisions This Supports

• Build vs. buy for the media picker. The core artifact — a browse/search/paginate/upload/preview modal with single and multi-select — is ~2–4 engineer-weeks of undifferentiated work. This package collapses it to a single Blade tag (<livewire:media-selector wire:model="media" collection="gallery" />) plus a composer require. That is a scoping decision you can make in a sprint planning meeting rather than a roadmap quarter.
• Sequencing the admin roadmap. Because the picker is cheap, "image upload on the CMS forms" stops competing with "richer media management" for the same slot. Ship the picker now, defer the DAM (folders, tags, cropping, chunked/cloud uploads — all listed as planned, none shipped) until usage justifies it.
• Information architecture via collections. collection="avatars" vs collection="gallery" is the package's primary organizing lever and it is a product-modeling decision, not a technical one. Choosing collections over per-feature tables or separate disks locks in how content editors think about assets — worth an explicit decision, since the package re-validates every selection against the active disk/collection/owner scope.
• Market and localization scope. Shipped RTL support (auto-detected for Arabic/Kurdish) and bundled EN/AR/CK translations with publishable lang files mean an Arabic-first or Kurdish-market launch is not gated on a UI rebuild. This is a genuine expansion-enablement argument, not a checkbox.
• Content moderation policy. Soft delete, restore, and an optional trash tab let you decide whether editors can hard-delete assets or whether deletion is reversible and gated. That is a governance decision the component exposes as configuration (canDelete, canSeeTrash, canRestoreTrash) rather than as custom code.
• Permissions posture. The :can-delete / :can-upload flags are meant to be fed from your own policies/gates. This forces the useful product conversation — "who is allowed to delete a client's hero image?" — early, instead of after an incident.
• Framework upgrade as a forcing function. v4 requires Laravel 12–13 and PHP 8.3+, and explicitly drops Laravel 11 (security-fix EOL March 2026). If your platform team is on 11, adopting this package silently becomes a framework-upgrade commitment. Model that in the same decision, not after.
• Exit cost is low enough to be a real option. MIT license, one migration, one Blade component, publishable views and assets. If you publish the views you own the markup and can iterate on design without filing upstream issues — meaning "buy" here does not create the usual lock-in debt.

When to Consider This Package

Adopt when:

• You are already on Laravel 12–13, PHP 8.3+, and Livewire 3.5+/4. This is a hard gate, not a preference.
• Your admin surface is Livewire + Tailwind. The UI is Tailwind-only — no Bootstrap, no custom design system without rewriting the published Blade views.
• You need a picker on one to five forms in the next few weeks and the out-of-the-box look is acceptable to your team. Getting one component live is the cheapest possible evaluation.
• A single maintainer with a small user base (20 stars, 0 dependents) is an acceptable support model — because you have read the source, can publish and own the views, and have a fallback plan.
• You are willing to pin versions and read the changelog. Three majors have shipped with documented breaking changes, including a v4 security release that #[Locked]ed all permission and storage properties. Older lines (1.x) predate that work and are not an acceptable production target.
• You can live without SVG uploads (disabled by default for stored-XSS reasons) or will sanitize them yourself.

Look elsewhere when:

• You are on Laravel ≤11. You would be pinned to 1.x, which lacks the security hardening — treat this as a hard no, not a tradeoff.
• Your frontend is Vue/React/Inertia with no Livewire. The component is not reusable there.
• You need a digital asset management system, not a picker: folders, tags, favorites, metadata filters, crop/rotate/resize, chunked/resumable or direct-to-cloud uploads are all planned, not delivered. Budgeting for them is budgeting for vaporware.
• You need transformation pipelines, CDN delivery, or responsive derivative generation — pair with or buy a dedicated media library/CDN service instead.
• Procurement requires an SLA, vendor security review, or a named support contract. There is one developer and no commercial backing.
• You are on a non-Tailwind design system and cannot absorb the CSS rewrite.
• You intend to make the package's media table your system of record and you have complex ownership/multi-tenancy rules. The config exposes table and model so you can point at your own, but decide this before writing the migration — retrofitting a canonical media model after assets exist is the expensive version.

How to Pitch It (Stakeholders)

For executives — the decision in one line: We can buy a working media picker for our admin in an afternoon instead of building one over the next sprint or two. It is MIT-licensed, it is a single component plus one database table, and if it disappoints us we remove it without a rewrite.

The business case:

• Cost avoided: a browse/search/upload/select/preview modal with validation, pagination, soft delete, and i18n is roughly 2–4 engineer-weeks of work that adds no product differentiation.
• Time to value: one composer require, one published migration, one Blade tag. A demoable picker in the same day.
• Downside if wrong: low. Publishable views mean we own the UI. One table and one component mean the removal cost is measured in days, not a quarter.
• Upside we would not otherwise buy: RTL support and Arabic/Kurdish translations ship in the box, which de-risks our regional expansion timeline.

For engineering — the honest caveats to state up front:

• Hard prerequisites: Laravel 12–13 and PHP 8.3+. Our current framework version determines whether this is even in scope; resolve that first.
• Pin to 4.x. v4 is the release that locks permission and storage properties against client-side tampering; earlier lines had a real privilege/tampering exposure. Do not backport to 1.x.
• Security posture is sound if we do our part: permissions must come from our policies and gates, and SVG stays disabled unless we sanitize uploads.
• Single maintainer, 0 known dependents — we are an early adopter. That is acceptable only because we can read the source and own the views.

What I need approved: adoption for the admin CMS forms specifically (not a general DAM mandate), a version pin with a changelog review at each upgrade, and a named engineer to own the published views and config as our fork-in-place surface.

What I am explicitly not asking for: committing to the roadmap items (folders, tags, cropping, chunked uploads). If those become requirements, that is a new build-vs-buy decision, not a promise this package has already made.