Filament Locationpickr Field Laravel Package

Technical Evaluation

Architecture fit. This is a presentation-layer artifact: one Filament form field that renders an interactive map, captures a point, and hands back a latitude/longitude pair for the host model to persist. It ships no domain logic, no schema of its own, no queue workers, no scheduled work, and no meaningful bootstrapping beyond field registration. For a TPM that is the best possible shape for a bounded back-office widget — the blast radius is one form schema, removal is a composer remove plus a column decision, and it cannot leak business rules into the domain layer. The reframing that matters is that the package is the small half of what we are actually approving. Adopting it commits us to two platforms: Filament 5 at the framework tier, and a metered map provider (Google Maps JavaScript + Places per the package description) at the commercial tier. The field is a thin adapter between them; our real dependency is the adapter's upstreams.

Integration feasibility. Engineering effort is measured in hours: require the package, optionally publish config/views, add the field to a form schema, add two nullable decimal(10,7) columns, seed a default center/zoom. In a Filament 5 panel this is a same-sprint spike with time left over. The gating work is organisational and will dominate the critical path — provisioning a Google Cloud project, enabling Maps JavaScript and Places, minting a browser key restricted by HTTP referrer and API, setting quota caps and budget alerts, and clearing privacy/ToS review. In most enterprises that sequence outlasts the coding by weeks, so plan the schedule around procurement rather than around the engineer.

Technical risk.

• Adoption signal is effectively nil. One star, zero dependents, a single maintainer, and a major-version changelog consisting of the line "support filament 5." There is no public evidence of production use. For a field this small that is tolerable, but we should record in the risk register that we would be among the first meaningful adopters rather than learn it during an incident.
• Provider ambiguity in the documentation. The description calls it a Google Maps field while also referencing Leaflet, and LocationPickr is historically a Leaflet-oriented library. Whether we are signing up for a metered Google relationship, an open tile provider, or a hybrid with Google Places for search materially changes cost, ToS, and privacy exposure. This must be settled by a code read, not by the README.
• Terms-of-service and data retention. Places Autocomplete carries caching and storage restrictions. Persisting only lat/lng is broadly safe; persisting place IDs, formatted addresses, or place names long-term may not be. The answer determines whether the feature is shippable and belongs in the first hour of review.
• Cost is usage-shaped. Maps JS loads and Places requests are metered per call. A dozen operators is noise; a large ops org doing high-frequency lookups is a recurring line item that a budget owner will not expect from an "MIT-licensed" dependency.
• Double upstream coupling. Filament majors move yearly and Google deprecates Maps/Places surfaces on its own cadence. After either kind of change we depend on a one-person project to keep pace, with no SLA if it does not.
• No documented degradation contract. It is unclear whether the field falls back to manual coordinate entry when the key is absent, quota is exhausted, or Maps JS fails to load. Silent workflow blocking in an admin panel is the failure mode that manufactures support tickets.
• Accessibility and localisation unverified. Drag-a-marker and click-to-select are not keyboard-navigable by default, and tile/label rendering may not satisfy every user region.

Key questions.

• What does composer.json actually pin — PHP, Laravel, and Filament floors? That read is faster and more honest than the README.
• Which map provider does the code actually initialise, and does address search hit Google Places specifically?
• Does the field persist anything beyond lat/lng, now or in its config options?
• What is projected monthly Maps spend at realistic ops volume, and who owns the budget line, quota caps, and key rotation?
• Does it degrade to manual lat/lng entry on API failure, and is it keyboard-operable?
• Build-vs-buy: a self-built Filament field over Leaflet/MapLibre plus a geocoder is roughly one to two engineer-days and removes Google as a permanent relationship. What does the vendor buy us concretely — address-search quality — and is that worth standing governance overhead?
• Will the maintainer keep publishing for the previous Filament major, and what is the test matrix?
• Does the field honour panel locale, and are tiles/labels acceptable for our user regions?

Verdict. A small, cheap, removable field wrapped around a larger and more permanent external relationship. The package is not the decision; the map provider and the Filament major are. Proceed on an already-scoped back-office screen, on Filament 5, with a named owner for provider-side change — and run a same-sprint bake-off against a self-built alternative, because at this adoption level writing it ourselves is a credible and possibly preferable outcome.

Integration Approach

Stack fit. Laravel + Filament 5 admin panel, with the target model carrying nullable latitude/longitude. It fits nowhere else: no API surface, no customer-facing page, no console command. Confirm the package's PHP and Laravel floors against the panel's existing constraints before sequencing — an unmet PHP floor quietly converts a one-hour integration into an environment change with its own regression surface. Where the panel is pinned to Filament 3 or 4, this is not an integration task at all but a forcing function for a full admin-framework migration; treat that as a separate, separately funded decision and do not let a map widget be the reason for it.

Migration path. Frame this as net-new capability on a net-new screen, because there is nothing to migrate — no legacy data to backfill, no prior geo workflow to retire. The one durable commitment is the data model: adopting this means latitude/longitude become first-class numeric columns, which shapes every downstream distance query, geo index, and report for the life of the feature. Choose plain nullable decimals and resist spatial column types for a picker. Store enough raw provider context alongside the point (formatted address or raw response) that a coordinate can be re-derived or re-verified if the widget is replaced, while keeping retention inside the provider's ToS.

Compatibility. Three axes to verify, in this order: (1) Filament major — v5.0.0 targets Filament 5 and should be assumed to drop 4 until proven otherwise; pin explicitly. (2) PHP/Laravel floors in composer.json. (3) Provider API generation — legacy Places versus Places API (New) is a live fork in the road and the package's support for the current generation is unstated. Also inventory every other Filament plugin in the panel: the classic Filament 5 failure is a panel with one lagging plugin, and render-time breakage does not appear until a form loads.

Sequencing.

1. Diligence read (½ day). composer.json floors, source review for which provider is initialised, what is persisted, and whether a manual-entry fallback exists. Cheap, and it can end the evaluation.
2. Procurement in parallel (weeks, and the true critical path). Google Cloud project, Maps JavaScript + Places enabled, browser key with referrer and API restrictions, quota caps, budget alerts, named owner, privacy/ToS read-off.
3. Spike on a secondary panel. Require, register, render a real form. Wrap the affected resource in a smoke test that boots the panel and asserts a 200 before and after.
4. Wrap, don't scatter. Expose the vendor field through a one-line internal field class so every usage site is unchanged if we swap to a self-built or non-Google picker.
5. Promote to one scoped screen with a plain numeric lat/lng fallback input beside it, so a key or quota failure degrades the experience rather than stopping the workflow.
6. Document rollback — composer.lock revert plus any republished config or views — before this reaches production.

Operational Impact

Maintenance. We inherit very little code and a disproportionate share of upstream churn. Two independent clocks govern our exposure: Filament majors, which will require a coordinated bump of this package with the panel and every other plugin, and provider API deprecations, which arrive on the vendor's schedule with notice but no coordination with a one-maintainer project. Assume an internal owner for the adapter exists. Budget the realistic carrying cost as a recurring small tax on every Filament upgrade plus an unpredictable line item on every provider deprecation — not as "MIT, therefore free."

Support. There is no vendor, no SLA, and no security-response commitment. The mitigation is structural, and it only works if we build it now: the source is small, permissively licensed, and confined to a presentation boundary, so fork-or-replace is credible rather than aspirational — provided we have wrapped it in an internal field class and kept a self-built path costed at one to two engineer-days. Escalation paths are internal by construction; a TPM should record that explicitly so no stakeholder assumes a support relationship exists.

Scaling. Two dimensions, and only one scales for free. Adding operators or records is linear in admin usage and costs nothing in the package itself. Adding address lookups scales the metered spend directly — this is usage-shaped, not seat-shaped, so a budget owner who approved "a free MIT package" must see the per-lookup economics and the quota caps before launch. Keep the field back-office only: placing metered map loads on a customer-facing page creates both a cost and an abuse surface, and that is a product boundary worth writing down rather than assuming.

Failure modes. Rank by likelihood and blast radius:

• Missing, restricted, or expired API key — form renders but the map never initialises; operators cannot save a location. Mitigated by the manual lat/lng fallback.
• Quota exhaustion or budget cap hit — identical symptom, arrives mid-month with no warning to the operator. Mitigated by alerts to a named owner, not to a shared inbox.
• Filament major bump with a lagging package — render-time fatal across every resource using the field, discovered by users rather than CI. Mitigated by panel-boot smoke tests and a single reviewed upgrade set.
• Provider-side API deprecation — silent or loud breakage with an upstream maintainer who may not respond. Mitigated by the internal wrapper and a pre-costed replacement.
• ToS violation from over-persisting place data — not a runtime failure but a compliance one, and unrecoverable by rollback. Mitigated by the diligence read happening before sign-off.
• Keyboard/accessibility gaps — an inclusion defect that surfaces in audit rather than in incident, with no upstream fix path.

Ramp-up. For engineering, hours: one example form, one README, done. For whoever owns the Google Cloud relationship, days-to-weeks: key restrictions, quota and budget configuration, and the privacy/ToS interpretation, none of which the package documents. For support staff, near-zero — which is precisely why an undocumented degradation path is dangerous; if quota runs out and the field simply stops working, first-line support will have no prior context. Ship with a short runbook covering what a blank map means, who to notify, and how to fall back to manual coordinates. Total time-to-first-screen is dominated by procurement, so sequence the engineer behind the Cloud project rather than in front of it.