Filament Image Or Video Laravel Package

Technical Evaluation

Architecture fit. The package targets Filament's form-schema model — a custom field that accepts either an image or a video and renders an appropriate preview in the admin panel. That is a natural extension point: Filament fields are composable, live in the form schema alongside FileUpload, TextInput, etc., and require no changes to our domain or persistence layers. Architecturally the fit is high; strategically the value is narrow, because the underlying capability is a thin configuration wrapper over Filament's stock FileUpload (acceptedFileTypes, image(), maxSize, disk/directory, preview). We are buying convenience, not a capability we cannot build.

Integration feasibility. Mechanically simple: composer require wotz/filament-image-or-video, register the field in a resource form, point it at a disk. The real feasibility questions are version coupling (which Filament major it targets — v3 vs v4 have divergent field/asset APIs) and whether video preview implies server-side poster-frame generation (ffmpeg dependency) or just an HTML5 <video> tag in the preview. The latter is a materially different operational footprint.

Technical risk. High relative to the value delivered:

Key questions. Which Filament major(s) are supported, and is there a version constraint or just *? Does it extend FileUpload or reimplement upload logic? Is there CI/tests? Does video preview require ffmpeg or a poster-frame service? Does it support private/S3 disks with signed URLs? Any production users, and what is issue-response history? What is the total LOC — i.e., is vendoring cheaper than depending?

Integration Approach

Stack fit. Laravel + Filament panel + Livewire uploads + filesystem disk abstraction. If the field correctly delegates to FileUpload, it inherits disk config, visibility, temporaryUploads, and S3 support for free. Any deviation from that delegation is a red flag and a reason to reject.

Migration path. Do not take a hard Composer dependency on day one. Two viable options, both cheap given the MIT license:

1. Vendor the field class into app/Filament/Forms/Components/ (likely tens of lines) and own it outright.
2. Wrap it in an internal MediaUpload component so we can swap implementation without touching every resource.

Either removes the upgrade-coupling risk and preserves the ergonomic win.

Compatibility. Pin our panel's filament/filament constraint, verify against our PHP and Livewire versions, and confirm asset registration behavior (Filament v4 changed asset handling). Add a smoke test that renders the form and asserts accepted types.

Sequencing.

1. Timeboxed spike (≤1 day) in a sandbox panel: install, render, upload image and video, inspect generated markup.
2. Read the source; decide vendor vs. wrap vs. build.
3. Baseline comparison: replicate the behavior with stock FileUpload — realistically half a day — and compare against the spike output.
4. Pilot in one low-risk internal resource behind a feature flag.
5. Staging validation matrix: jpg/png/webp, mp4/webm/mov, oversize file, wrong MIME, S3-backed disk, private disk.
6. Decision gate: adopt vendored, adopt as dependency, or build in-house. Given the score profile, "build in-house" is the likely outcome and the package's real value is as a reference implementation.

Operational Impact

Maintenance. Assume we own it. A 0-star, 0-dependent package gives us no ecosystem pressure to fix bugs and no upstream to lean on. Budget a few hours per Filament major upgrade either way; vendoring makes that cost explicit rather than a surprise when Composer resolution breaks.

Support. No vendor, no SLA, GitHub issues only, likely no community. Internal knowledge must be documented at adoption time; do not let a single developer hold it implicitly.

Scaling. The package is not the bottleneck — video storage and delivery are. Expect storage growth, egress costs, and admin-panel bandwidth to dominate. We need max-size caps enforced server-side, CDN or signed-URL delivery, and likely an async transcode/poster pipeline that is explicitly out of scope for this package. If the field does synchronous video processing, that is a scaling and memory-exhaustion hazard in the request path.

Failure modes.

• Silent preview failure for codecs the browser won't decode (HEVC/MOV in Chrome) — looks like a bug, isn't.
• Signed-URL expiry on private S3 disks breaking previews.
• Orphaned temporary uploads and disk bloat.
• Memory exhaustion on large images if server-side processing exists.
• Validation gaps allowing non-media or executable content through a widened accept list.
• Hard breakage on the next Filament major with no upstream fix.
• Abandonment: repo goes quiet, we discover it during an unrelated upgrade.

Ramp-up. Low — an hour for a Filament-fluent developer to use the field. The cost is not learning it; it is the ownership we inherit. Net assessment: conditional go for a spike and reference use; no-go as an unexamined production dependency.