Filament Leaflet Geosearch Laravel Package

Product Decisions This Supports

• Location capture in internal tools: Deciding whether admin/staff users should pick a point on a map (rather than type raw latitude/longitude) when creating or editing records such as stores, depots, service areas, delivery zones, assets, or event venues inside a Filament panel.
• Build vs. buy for map inputs: This package represents the "buy/adopt" option — a drop-in Filament form field wrapping Leaflet GeoSearch — versus building a custom field (Alpine.js + Leaflet + a geocoder) or purchasing a commercial map widget (Google Places, Mapbox).
• Feature scope for a single release: If geo entry is a small slice of a larger admin workflow, adopting a thin field is the low-investment path; if location is core to the product (routing, geo-fencing, spatial search), this dependency is too narrow and should be treated as a prototype only.
• Roadmap prioritization: Useful for scoping an MVP where "search an address, drop a pin, save coordinates" unblocks an operational workflow without committing to a mapping platform decision.
• Vendor/stack fit: A data point in the broader question of "how much of our admin UI should depend on third-party Filament plugins?" — relevant to a plugin-adoption policy, version-pinning strategy, and upgrade cadence for Filament majors.
• Not supported: customer-facing maps, turn-by-turn navigation, spatial querying/analysis, bulk geocoding of existing records, or any decision requiring a maintained, security-reviewed component.

When to Consider This Package

Consider it when:

• The host app is on Filament v2 (or whichever major the 2022 release targets) and you are not planning a Filament upgrade in the near term. Confirm compatibility explicitly before adopting — this is the single biggest go/no-go.
• The need is genuinely a form field: one location per record, captured manually by a staff member, stored as lat/lng (plus optionally an address string).
• You want a fast proof of concept — a spike, internal demo, or throwaway admin tool — where a few hours saved matters more than long-term ownership.
• Your team is comfortable vendoring or forking a small MIT-licensed package: the code surface is narrow enough that pinning a fork and patching it is realistic.
• You have a clear answer for tile and geocoder usage terms (e.g., OpenStreetMap/Nominatim usage policy, or a keyed provider) and the request volume is low and internal.

Look elsewhere when:

• You are on Filament v3/v4 or plan to upgrade — with a last release in September 2022 and ~22 stars, expect no upstream support for newer majors, PHP versions, or Livewire changes.
• The feature is customer-facing or revenue-critical — a single-maintainer package with no recent releases is not a defensible dependency for anything with an SLA.
• You need multiple pins, polygons, geo-fencing, radius search, saved map state, or server-side spatial queries — this is a single-value input field, not a mapping layer.
• Privacy or compliance constrains address data: geosearch typically means sending user-entered addresses to a third-party geocoding service. If addresses are personal data under GDPR or are otherwise sensitive, you need a self-hosted geocoder and a DPA review first.
• You need accessibility guarantees (keyboard-operable map picking, screen-reader alternatives) — map widgets commonly fail this, and a small package won't carry that work for you.
• Offline/air-gapped environments or strict CSPs that disallow third-party tile hosts.

Practical evaluation checklist before adopting: verify Filament/Laravel/PHP version constraints in composer.json; identify the geocoding provider and whether it requires an API key or has rate limits; check tile-server terms; inspect open issues for Livewire state-sync problems (a common failure mode for map fields in Filament); confirm the stored value format (lat/lng pair vs. GeoJSON) matches your schema; and time-box a one-day spike against your actual Filament version.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) open-source component that lets staff pick a location on a map inside our admin panel instead of typing coordinates — it removes a class of data-entry errors and saves a few days of build time on internal tooling. It is a tactical convenience, not a platform bet. The trade-off is maintenance risk: it was last released in 2022, has a very small user base, and may not survive our next framework upgrade. Recommendation: approve it only for internal, low-stakes workflows, with the expectation that we may replace it with a small in-house field or a commercial map widget if our needs grow or we upgrade Filament.

To engineering: Adopt as a pinned dependency behind a single form-field usage, not spread across the codebase. Confirm Filament major compatibility and the geocoder provider (and its API key/rate-limit/quota story) before writing it into a sprint. Assume we own the code: plan for a fork if it breaks, keep lat/lng as plain columns so replacing the UI later is a front-end-only change, and surface any third-party address transmission early so privacy/legal can weigh in. If the requirement is anything beyond "one address, one pin," propose building the field ourselves — the underlying Leaflet + geocoder integration is well-trodden and the dependency's small surface area means our build cost is not much higher than our maintenance cost.