Filament Focal Point Picker Laravel Package

Technical Evaluation

Architecture fit. This is a Filament form-field plugin, not a general-purpose Laravel package. It attaches to the Filament panel ecosystem via a plugin service provider and a Field subclass, with the interactive picking behavior implemented client-side (Alpine/Livewire) and assets registered through Filament's asset pipeline. That makes it architecturally a thin UI component with a very small persisted payload — the focal point is typically a pair of percentages (x/y) or a small JSON blob on the owning model. The critical architectural observation is that the package almost certainly ends at persistence: it captures intent but does not render it. Consuming the value on the front end (object-position, per-conversion focal cropping, responsive variants) is work you own. Budget for that gap explicitly — it is the difference between a one-day install and a two-week feature.

Integration feasibility. High, conditional on being a Filament shop. Install, register the plugin in the relevant PanelProvider, add the field to a resource form, add a cast/accessor, done — likely a few hours for a Filament-fluent developer. The interesting feasibility questions are in the seams: how the value is stored (two columns vs. JSON) drives migration and query ergonomics; whether the field supports nested state (repeaters, builders, relation managers) is unverified and is where Filament field packages most often break; and whether it plays with Spatie Media Library conversions or expects a single original-image URL. If you are not on Filament, stop here — the field itself is unusable, though the Alpine logic is trivially extractable.

Technical risk. The dominant risk is governance, not code. Single maintainer, 44 stars, zero dependents, MIT: there is no downstream validation and no commercial support. Filament ships majors roughly annually with meaningful breaking changes (v3 → v4 included namespace, asset, and Tailwind-generation changes), so any field package requires re-release per major; a solo maintainer's release cadence is your availability SLA. The 2026-03-06 release date is recent enough to suggest active maintenance but is worth confirming against actual commit history rather than the release tag. Secondary risks: unversioned or unpublished JS/CSS assets causing 404s in production builds; CSP and Livewire re-render state loss; and the silent-failure class below. Treat "opportunity: 20.47" as confirmation this is a commodity utility, not a strategic dependency.

Key questions.

1. How is the focal point persisted — discrete columns or JSON — and what does the accessor contract look like?
2. Does it support nested form state (repeaters, builders, relation managers) or only top-level fields?
3. Does it integrate with Spatie Media Library / conversions, or only raw image URLs?
4. Are JS/CSS assets precompiled and published via FilamentAsset, or does it require a host-side build step?
5. Which Filament majors and Livewire versions are actually in the composer constraint, and is there a stated v4 support commitment?
6. What is the commit cadence and issue-response history over the last 12 months, independent of the release tag?
7. Does it preserve or migrate existing crop data from whatever we use today?

Integration Approach

Stack fit. Laravel + Filament panel on PHP 8.1+, with the image dimension known at render time. If images are served through a transformation layer (Glide, imgix, Spatie conversions), confirm the focal point can be applied per-variant — otherwise editors will tune a focal point that only affects the original image, which is worse than no feature at all because it erodes trust in the admin.

Migration path. Add nullable focal-point storage with a default of center (50/50) so existing rows render identically before and after. Backfill deliberately, not implicitly. If a cropper is currently in use, run the two side by side behind a feature flag and cut over per resource type rather than globally — the failure surface is content-dependent, not code-dependent.

Compatibility. Verify the composer constraint against your exact Filament minor, not just the major, and confirm Livewire version alignment. Check whether the package ships precompiled CSS against Filament's Tailwind generation — this is the most common upgrade-break vector in this class of package. Pin the version in composer.json and treat upgrades as reviewable changes, not routine composer update drift.

Sequencing.

1. Dev-branch spike: install, wire one resource, verify asset publishing and production build behavior (not just php artisan serve).
2. Write the internal adapter: a thin custom Field subclass or Blade component that owns both the field configuration and the front-end object-position rendering. This is the single highest-leverage TPM decision here — it converts a third-party dependency into an internal seam you can swap in an afternoon.
3. Roll to one resource; validate on real aspect ratios (portrait, ultra-wide, transparent PNG) with content editors, not with test fixtures.
4. Extend to the media library / remaining resources.
5. Ship the front-end rendering path (CSS helper, responsive object-position, conversion integration) before announcing the capability.

Operational Impact

Maintenance. You are effectively forking this on day one. Zero dependents means no one else is finding the bugs first. Budget 1–2 days per Filament minor release and 3–5 days per Filament major for compatibility validation, plus a standing owner. Keep the pinned version and an internal changelog so upgrades are deliberate.

Support. No vendor, no SLA, no security-response channel. Issues arrive via GitHub at the maintainer's discretion. Mitigate with (a) the internal adapter, (b) a checked-in copy of the JS/Alpine source, and (c) a documented fallback: revert to a plain center-crop field, which is a sub-day change if the adapter exists and a multi-week change if the package is woven through templates.

Scaling. Negligible. Two floats per image row, no queries, no background work. All real cost lives downstream in image transforms and CDN behavior, which this package does not touch. One caveat: if focal points are baked into server-rendered markup or image URLs, changing a focal point must invalidate the relevant CDN cache keys — otherwise editors update a value and see stale output, which reads as a broken admin.

Failure modes.

• Silent no-op (most likely and most damaging): focal point saves correctly but is never applied on the front end. Editors adjust, nothing changes, confidence in the tool collapses. Gate rollout on the rendering path being live.
• Asset 404: JS/CSS not published or not included in the production build; field renders as a bare file input.
• State loss on re-render: Livewire round-trips resetting the picker, particularly on nested components.
• Upgrade break: Filament major bumps and the field fails to register or renders unstyled, often only in specific panels.
• Orphaned data: image replaced or deleted, focal point retained against a new image. Handle on the model, not in the field.

Ramp-up. Hours for a Filament-fluent engineer (the API is idiomatic and the codebase is small). Content editors need a short brief — the interaction is "click the part of the image that must stay visible," which is not universally intuitive and benefits from an inline hint in the field label. Design QA on real assets should be a required step; crop regressions surface visually and only on specific aspect ratios.

Verdict for the roadmap. Adopt as a bounded utility with an internal adapter, not as a platform dependency. The technical risk is low and the code footprint is small; the real risks are organizational — single-maintainer availability, an unowned front-end rendering contract, and silent failure in the last mile. All three are cheap to mitigate up front and expensive to discover in production.