Filament Locationpickr Field Laravel Package

Product Decisions This Supports

• Feature scoping for geo-aware admin surfaces. This package turns "let an operator drop a pin on a map" from a multi-day engineering task into a schema configuration line. The decision it unlocks is whether venue, store, delivery-point, asset, or field-visit records can capture coordinates natively inside the admin panel — and if that capability was shelved purely on build effort, this reopens it at near-zero marginal cost.
• Build vs. buy on a commodity widget. Rendering map tiles, wiring a draggable marker, and persisting two floats is undifferentiated work. Buying is defensible because it is undifferentiated — the saved engineering days should be redirected to the parts that are actually product: radius checks, nearest-branch routing, store-locator search, territory assignment, visit verification.
• A durable data-model commitment disguised as a form field. Adopting this means latitude/longitude become first-class numeric columns rather than a free-text address. That choice shapes distance queries, geo indexing, reporting, and every future map rendering for the life of the feature. Treat it as an architecture decision, not a UI one, and confirm the column pair (nullable decimal(10,7) is sufficient — resist spatial/geometry types for a picker).
• A vendor and budget line item entering the roadmap. Google Maps JavaScript + Places are metered, keyed, and bound by Terms of Service. Approving this field is implicitly approving a Google Cloud project, a referrer-restricted browser key, quota caps, budget alerts, and a recurring spend that scales with operator usage rather than seats. Someone must own that relationship before the feature ships — this is the decision most likely to be overlooked.
• Roadmap sequencing against the Filament major. v5.0.0 exists solely to track Filament 5. If a Filament upgrade is already funded, this rides along at negligible marginal cost. If the panel is pinned to Filament 3 or 4, adopting this becomes a forcing function for a full admin-framework migration — a far larger commitment than the widget, and a poor reason to upgrade.
• Explicit back-office-only positioning. The realistic use case is internal capture at low request volume, where a restricted key is safe and Maps spend is predictable. Deciding not to expose it customer-facing is itself a product decision worth recording, because it bounds both cost and abuse surface.
• A cheap experiment against an expensive alternative. If the alternative is a custom geo-picking surface or a third-party store-locator SaaS, a one-sprint spike on this field produces real signal on whether point capture earns its place on the roadmap at a fraction of the commitment.

When to Consider This Package

Adopt when:

• The admin surface is Laravel + Filament and is already on — or already funded to move to — Filament 5. Verify against composer.json, not the README.
• There is one concrete, already-scoped screen that needs point capture: venue records, service addresses, store or asset locations, visit check-ins. Not a speculative "geo someday."
• A Google Maps API key can be provisioned with billing enabled, key restrictions applied, and quota and budget alerts configured, under a named owner.
• The precision requirement is exactly "a point on a map." Click-or-drag-to-marker is the whole job.
• The team has confirmed in writing that the source is small enough and the MIT license permissive enough that fork-or-replace is a realistic fallback rather than an aspiration — one star, zero dependents, and a single maintainer make this a genuine consideration.
• A self-built alternative (Leaflet/MapLibre field plus a geocoder) is not obviously cheaper once Google's address-search quality is factored in.

Look elsewhere or defer when:

• You need a validated address, not a coordinate. The field yields lat/lng; it does not produce a normalised postal address. If invoicing, shipping, or CRM needs parsed address fields, this is half a solution and you still need a geocoding service.
• Provider neutrality matters. Mapbox, Leaflet/OpenStreetMap, or Here means a fork or a different package. If Google's pricing, terms, or data-residency posture is a blocker, settle that before adoption rather than in security review.
• You need shapes, routes, or multi-point areas. Geofences, delivery polygons, and routing are outside a marker field's remit.
• The map is customer-facing or high-volume. Metered Maps calls on a public page are both a cost and an abuse surface. Keep this behind authentication.
• Regulated or EU users' precise coordinates are involved. The field itself isn't the risk, but tiles and Places requests leave the browser for a third party — confirm that fits the privacy posture first.
• You require vendor support, an SLA, or security-response guarantees. One star, zero dependents, and a one-line release note do not meet that bar without a deliberate internal-ownership decision.
• Filament isn't in the stack, or you're on Filament 3/4 with no funded upgrade. Migrating the admin framework to adopt a small form field inverts the cost/benefit entirely.
• Release hygiene can't be verified. The v5.0.0 note reads "support filament 5" with no migration guide and no stated breaking changes. Read the diff, check real PHP/Laravel/Filament floors, and confirm whether Filament 4 support continues before betting a workflow on it.
• The field persists more than lat/lng without review. If it also stores place IDs or formatted addresses, that may run against Google's caching and storage terms — a short code read that must happen before sign-off.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed admin-side dependency that converts "drop a pin on a map" from a custom build into a configuration step. It supports internal tooling — venues, delivery points, branch locations — not a customer-facing capability, so the return is delivery speed and avoided maintenance on code we would otherwise own. Two costs to state plainly. First, Google Maps usage is metered and needs a provisioned, restricted key with spend caps and a named budget owner; "MIT-licensed" does not mean "free." Second, the package is thinly maintained — v5.0.0 tracks the current Filament major, but the changelog is a single line and the project has essentially no community footprint, so we should assume we are among its first production adopters. The mitigation is that the code is small and permissively licensed, so fork-or-replace is credible. Recommendation: approve as a time-boxed evaluation tied to the next internal-tooling initiative, contingent on Filament 5 already being on the roadmap and a reviewed Maps API budget — not as an opportunistic standing dependency.

For engineering: v5.0.0 targets Filament 5 and should be treated as a breaking change until proven otherwise; do not assume dual Filament 4 support. Pin the version explicitly, read composer.json for the real PHP/Laravel/Filament floors, and upgrade Filament core, this package, and every other Filament plugin in the panel as one reviewed set — the most common failure mode is a Filament 5 app with one lagging plugin. Register the field on a secondary panel first and load a real form, because plugin breakage is render-time, not boot-time; wrap the affected resource in a smoke test that boots the panel and asserts a 200 before and after the bump. Scope the Google key server- and environment-side, restrict it to Maps JavaScript + Places with referrer restrictions, and set quota caps and budget alerts. Persist the coordinate pair alongside enough raw provider context (formatted address or raw response) that the point remains recoverable if the widget is replaced, and confirm what the field actually writes before sign-off, since storing place IDs or addresses long-term has Terms-of-Service implications. Wrap the vendor field in a one-line internal field class so swapping to a self-built or non-Google picker is a single-file change, keep a plain numeric lat/lng input as a fallback so a key or quota failure degrades the experience rather than stopping a workflow, and hold a documented rollback — composer.lock revert plus any republished config or views — before this reaches production.