Filament Google Map Location Picker Laravel Package

Product Decisions This Supports

• Build vs. buy on geo data capture. If your roadmap includes "admins/users pick a point on a map and we store lat/lng," this package is a buy-side option priced at zero. The decision it informs is whether a 30-minute composer install plus a Google Maps API key beats a 1–3 day internal build of a custom Filament field with the Maps JS SDK. The v2.2 release (zoom control configuration plus small fixes) does not change that math — it's a UI polish increment, not a capability that removes work from your side.
• Feature scoping for location-aware admin workflows. Concretely, it unblocks: store/branch locator records, delivery-zone or service-area definitions captured per record, field-sales or asset records with coordinates, property/listing pinpoints, and event venues. The PM question is whether point-picking (single lat/lng) is sufficient, or whether the roadmap actually needs address autocomplete, reverse geocoding, polygons, or multi-stop routes — this package only reliably addresses the first. The new zoom-control option is a map-presentation tweak; treat it as evidence the widget is being maintained at the margins, not as movement toward any of those roadmap items.
• Reducing engineering drag on internal tooling. The value is not the map; it's not writing and maintaining the JS glue, validation, and Filament state hydration for every geo field. That is real, if modest, savings on internal admin surfaces where polish expectations are low.
• Informing a "make the geo field a platform primitive" decision. If more than one internal app or more than two models need coordinates, treat this as a reference implementation to fork into your own Filament field package, so the Maps provider, API key config, zoom/control defaults, and coordinate schema stay under your control. That's a roadmap decision this package's source can accelerate — and a fork is also the cleanest way to consume a release like v2.2 without inheriting a moving dependency.
• Risk acceptance on vendor maintenance. It tells you what a "thinly maintained dependency" looks like: small star count, no meaningful dependents, a multi-year gap in releases (nothing between November 2022 and this v2.2), and now one minor release consisting of a control option and small fixes. The decision this supports is explicit: either accept that you effectively own this code, or don't take the dependency. v2.2 is a mild positive signal — someone is still in the codebase — but one minor release after a long silence is not a maintenance guarantee, and it does not by itself justify betting roadmap features on it.

When to Consider This Package

Adopt when all of these hold:

• Your app is on the Filament version this was built for. The v2.2 version number is consistent with the existing 2.x line rather than a new major, and nothing in the release notes indicates Filament v3/v4 support. Verify against your installed Filament major before estimating anything — a v3/v4 mismatch still turns a one-line install into a port.
• The need is a single coordinate per record, entered by a trusted internal admin, with no customer-facing map UX.
• You already have a Google Maps API key and billing in place, and your product/legal posture permits Google's terms and the associated usage costs.
• The surface is low criticality: if the field breaks after a Filament upgrade, an admin can paste coordinates manually while you fix it.
• You are willing to vendor or fork it. A first minor release after a three-year gap with no dependents is a signal that the package is alive, not that it is supported. Forking remains the sane path; a bare require is not.

Look elsewhere when:

• You need address search / autocomplete / reverse geocoding. That's a Places API integration with its own cost model and latency budget — not a picker widget. Budget it as a feature, not a dependency. Nothing in v2.2 moves this needle.
• You need polygons, radius drawing, multi-point, or route geometry. Delivery zones and service areas are a different data model (spatial columns, spatial indexes, PostGIS or MySQL spatial functions) and a different UI. A zoom-control flag does not get you there.
• You are on Filament v3/v4. Evaluate maintained alternatives or a first-party build; a v2.2 package release is not evidence of forward compatibility with newer Filament majors.
• Map provider choice is contested. If cost, privacy, or regional coverage pushes you toward Mapbox, Leaflet/OpenStreetMap, or self-hosted tiles, taking a Google-coupled field now creates migration debt later.
• Coordinates feed customer-facing or revenue-critical logic (pricing by distance, dispatch, geofenced eligibility). Then you want owned code, tests, and a defined failure mode for missing keys or quota exhaustion.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source UI component that lets staff drop a pin on a Google Map when filling out a record, instead of typing latitude and longitude by hand. It removes a known source of bad geo data in internal admin screens for near-zero cost. It shipped a minor update recently — a zoom-control option and small fixes — which is a modest sign of life, but it follows a multi-year gap in releases and the project still has no meaningful user base or support commitment. We should treat it as a starting point we adopt and own rather than a supported product we depend on. Recommendation: use it as the basis for an internal geo field, budget roughly one to two engineer-days to vendor, verify, and test it, and don't build roadmap features — address search, service-area polygons, distance pricing — on top of it without a separate scope.

To engineering: Filament form field wrapping the Google Maps JS SDK; stores a coordinate pair on the model. Assume Filament v2-era API — confirm compatibility first; the v2.2 release adds zoom-control configuration and small fixes but shows no sign of a Filament major-version migration. Verify: field state hydration/dehydration, validation on missing/partial coordinates, API key configuration path, how the new zoom control option defaults, and graceful degradation when the key is absent or the quota is exceeded. Plan to fork into an internal package, pin the Filament version it targets, add a smoke test, and document the coordinate schema so downstream spatial queries aren't coupled to the widget. If the roadmap includes geocoding or polygon geometry, flag it now — that changes the data model and is not this package's job.