Filament Map Picker Laravel Package

Product Decisions This Supports

• Feature scoping for location capture. This package answers a recurring "do we need to build a map field?" question for any Filament admin surface that stores a point: store/asset locators, delivery or service zones (point + radius), property and listing records, event venues, field-service job sites. If the requirement is "pick a point, save lat/lng," this is a candidate to evaluate instead of scoping a custom Leaflet field.
• Build vs. buy, sized correctly. The scope is small — a Leaflet/OpenStreetMap-backed form component that writes latitude and longitude to two decimal columns. Internal estimate for equivalent in-house work is roughly 1–3 engineer-days including the form-field integration, validation, and the "map doesn't render until the tab is visible" class of bugs. That framing should drive the decision, not the package's star count.
• Roadmap sequencing. This is an enabler for location-aware features, not a differentiator. It belongs in "unblock the admin MVP" work, not in a customer-facing release plan. If location is on the roadmap only as an internal ops convenience, this is a plausible shortcut; if location is a headline product capability, the map UI will outgrow it.
• Risk-tiering the dependency. 59 stars, zero dependents, a single maintainer, and a last release of 2023-11-20 place this in the "vendor the code, don't trust the upstream" bucket. That is itself a product decision: we would adopt it as source we own, pinned and forked, rather than as a semver-tracked dependency.
• Compliance/data-residency inputs. Because the default tile source is OpenStreetMap rather than a paid geocoder, adopting it avoids shipping customer coordinates to Google or Mapbox by default — relevant if a privacy or vendor review is on the critical path.

When to Consider This Package

Adopt it when all of the following hold:

• The application is on Filament v3 and has no near-term plan to move to v4. This is the single biggest gate — a 2023 release against a fast-moving admin framework is likely to break on the next major.
• The surface is internal or admin-only, where a broken map degrades an operator's workflow rather than a customer's experience.
• The requirement is genuinely point capture — latitude/longitude plus optional zoom — and not address search, reverse geocoding, polygon drawing, multi-stop routing, or map clustering.
• Your team can fork and own a small Blade/Livewire component. Budget a half-day to read it and a half-day to patch it if needed.
• The two decimal(10,7)-style columns fit your schema; no migration or data-model rework is implied.

Look elsewhere — or build the field in-house — when:

• You are on, or migrating to, Filament v4, or you need a maintained component with an active issue tracker.
• You need address autocomplete or geocoding. Pairing a dedicated geocoder (Mapbox, Google Places, Nominatim self-hosted) with a custom field is the better shape; a picker-only component will force a second integration anyway.
• You need drawing tools, polygons, radius search, or routing. Leaflet.draw plus a custom field, or a commercial map SDK, is the realistic path.
• The feature is customer-facing and long-lived. Single-maintainer, zero-dependent packages are a poor foundation for a surface you will support for years.
• You have procurement, SLA, or security-review requirements that a community package cannot satisfy.
• Your basemap policy mandates a specific provider (Mapbox/Google/self-hosted tiles) with keys, quotas, and attribution terms — you will be reimplementing the tile layer regardless.

How to Pitch It (Stakeholders)

To executives: There is a small open-source component that adds "drop a pin on a map" to our admin panel in about a day instead of the one to three engineer-days it would take to build. It is free, it uses OpenStreetMap tiles so there is no per-map-load bill, and it stores plain coordinates in our own database — no lock-in. The caveat is maintenance: it is a one-person project with a 2023 release and effectively no user base. My recommendation is to treat it as starter code we copy into our repo and own, not as a dependency we trust to keep working. That converts an uncertain vendor risk into a known, small, internal maintenance cost, and it lets us ship the location field this sprint. If location later becomes a customer-facing feature — address search, delivery zones, routing — we should expect to replace it and should plan that work explicitly rather than inherit it.

To engineering: Evaluate as a vendored Filament v3 form field: a Livewire component wrapping Leaflet, emitting lat/lng into two decimal columns. Confirm it renders correctly inside tabs, modals, and repeaters, and that it degrades gracefully when tiles fail to load or JS is blocked. Pin the commit, vendor the source, and add a smoke test around the form field's hydration and dehydration so an upstream abandonment cannot silently break admin. Do not add it to the dependency-update rotation. If we go to Filament v4, assume this is a rewrite and schedule it as such.