Filament Map Picker Laravel Package

Technical Evaluation

What the package is. humaidem/filament-map-picker is a Filament form-field plugin that renders an interactive map (Leaflet-based) inside a panel resource form, letting an editor drop a pin or search a location and returning a coordinate value for persistence. It is a UI-layer package: it adds one field class, a Blade view, and front-end assets. It ships no migrations, no models, no API surface, and no background processes. That small surface area is the single most important fact in this evaluation — it means the risk is concentrated and containable, not diffuse.

Architecture fit. Good, with caveats. Filament's field contract is well-defined (Field subclass, ->view(), asset registration through the panel's asset pipeline), so the package slots in the way any Filament form component does. It does not couple to your domain model, so it can't fight your architecture. The real fit question is not "does it work with Laravel" but "does it work with our Filament version and our geospatial storage convention." As of the last release (Nov 2023) the package targets the Filament v3 line; a v4-era panel is a likely incompatibility. Treat the package as a replaceable leaf component, not as infrastructure.

Integration feasibility. High for a spike, moderate for production. Installation is a single composer require, plugin registration in the panel provider, and a field added to a form schema — hours, not days. The unknowns are all about the value contract: whether the field returns a single serialized string ("lat,lng") or expects two separate columns, what precision it emits, and whether it validates bounds or accepts empty state. Resolve that before designing the schema, because retrofitting a coordinate column type is the expensive kind of change.

Technical risk. The dominant risk is project health, not code quality. Indicators:

Secondary risks: reliance on a tile provider (OpenStreetMap and most free endpoints have usage policies and rate limits — a production panel with heavy map use can violate them), GDPR/DPN implications of browser requests to third-party tile servers, and JS asset loading behind strict CSP or air-gapped networks.

Key questions to answer before committing.

1. Which Filament major version does our target panel run, and does this package's field class satisfy it? (Spike this first — it can kill the option.)
2. What exactly does the field emit on save — one string, an array, or two attributes — and what column type/precision does that imply?
3. Is the tile URL configurable (self-hosted, MapTiler, Mapbox) or hard-coded to a public endpoint? Who owns that key and its cost?
4. Is there any server-side validation of coordinates, or is the value trusted as submitted?
5. Do we need geocoding/search (address → pin), or is pin-drop sufficient? Search typically implies a paid geocoder and a different build.
6. Is the package's licence and asset provenance acceptable to our legal/security review?
7. How many lines is it, really? If the answer is "a few hundred," forking is cheaper than depending.

Integration Approach

Stack fit. Laravel + Filament panel, PHP 8.1+, Composer-managed. No infrastructure impact: no queue, no cache, no cron, no external service beyond tile HTTP requests from the browser. It fits a standard Filament admin panel with no architectural concessions.

Migration path. Two credible paths, and the choice should be made deliberately rather than by default:

• Depend path — composer require humaidem/filament-map-picker, register the plugin in the panel provider, add the field. Fastest to value; accepts upstream staleness risk.
• Absorb path (recommended for anything beyond an internal tool) — treat the repo as reference implementation, vendor the field class, Blade view, and JS into app/Filament/Fields/ with attribution. Given zero dependents and a dormant release cadence, the marginal cost of ownership is low and the upgrade risk becomes ours to schedule rather than someone else's to ignore.

Pin the version explicitly in composer.json and record the tile provider decision in the ADR either way.

Compatibility. Verify against the actual Filament version in composer.lock and against our CSP headers. Confirm the Leaflet asset is bundled/published rather than pulled from a CDN — a CDN dependency is a hard blocker for air-gapped or CSP-strict environments. Confirm behaviour on the Filament create page and the edit page (existing-value hydration is a common failure point in map fields).

Sequencing.

1. Day 1 spike (0.5–1 day): install in a scratch branch, render the field, save and reload a record, capture the exact stored value and its hydration behaviour.
2. Schema decision: fix the lat/lng column types and precision now; write the cast/accessor if the field emits a composite string.
3. Pilot (1–2 days): one low-traffic resource, one editor, real data. Validate validation rules, required/optional state, and mobile/touch behaviour.
4. Decision gate: depend vs. absorb, based on spike findings and tile-provider answer.
5. Rollout: remaining resources, plus a documented fallback (manual lat/lng numeric inputs) so the form degrades rather than breaks.

Operational Impact

Maintenance. Low effort, non-zero attention. Expect no upstream fixes; budget a periodic review (once per Filament upgrade) to confirm the field still renders. If absorbed, maintenance is a handful of files you already understand — realistically under a day per year. Add a composer outdated note or a dependabot-style reminder so the pinned version doesn't silently rot.

Support. Community-only: GitHub issues with an unknown response time. There is no vendor to escalate to, so internal ownership must be named. Document the field in the team's internal component catalogue — the failure mode here is not "it breaks" but "nobody remembers how it works when it does."

Scaling. Client-side only, so it scales with browser sessions, not with server load. The scaling constraint is tile traffic and terms of service: free public tile servers are not provisioned for internal-tool volume at scale. Choose and fund a tile provider up front (self-hosted tiles, MapTiler, Mapbox), keep the key server-configurable, and set a usage budget. Coordinate storage scales trivially; index only if you later add proximity queries (which this package does not provide — geospatial search is a separate, larger decision).

Failure modes and mitigations.

Ramp-up. For a developer already fluent in Filament, roughly half a day to spike, one to two days to production-ready including schema and validation. For a team new to Filament form customisation, add a day for the field/asset lifecycle. Editor-side training is near zero — a map with a pin is self-evident, which is precisely the product value: it replaces error-prone manual lat/lng entry with a direct-manipulation control.

TPM bottom line. Technically a good fit and operationally cheap, but the ecosystem signals (dormant, zero dependents, single maintainer) mean it should be adopted as absorbed internal code rather than an external dependency, and only after a one-day spike confirms Filament-version compatibility and the exact stored-value contract. The decision that actually carries cost is not the package — it's the tile provider and the coordinate schema, both of which outlive the library.