Filament Maps Laravel Package

Product Decisions This Supports

• Feature feasibility for location-aware admin: This is a narrow, well-defined capability — put a map in a Filament form, let an operator drop a pin, persist latitude/longitude. It unlocks a specific class of roadmap items (store locator records, delivery/service zones as a single point, site/asset addresses, field-visit check-ins) that would otherwise be blocked on "we need a map widget."
• Build vs. adopt, with real numbers: The honest internal build is a custom Filament field wrapping Leaflet or Mapbox — roughly 2–5 engineering days plus ongoing ownership of tile-provider keys, JS bundling, and Filament upgrade churn. The adoption case rests on that being cheaper than a Composer dependency. At 0 stars and a single 2024 release, that trade is only favorable if you treat the package as starting material to fork, not as a maintained upstream.
• Data-model commitment (the decision that outlives the package): Choosing a point-picker steers you toward two lat/lng decimal columns and a radius-search approach (ST_Distance / bounding box). If a later requirement is "draw actual delivery polygons," "assign multiple stops per route," or "find within arbitrary boundary," this package does not cover it and the schema decision becomes the expensive part, not the widget. Decide the geo model deliberately; the widget is the cheap half.
• Filament major-version timing: The package targets Filament v3 and was last released 2024-09-02. If the admin is on v3 and staying there through the planning horizon, adoption cost is low. If a Filament v4 migration is anywhere on the roadmap, adopting this adds a dependency you will have to replace or fork mid-migration — a sequencing constraint worth recording explicitly.
• Scope-in vs. scope-cut: Because the widget is small, this is a low-risk way to pull a location feature into an upcoming release rather than cutting it. It should be scoped as a spike with a hard fork decision at the end, not as a platform standard.
• Use cases to prioritize: Internal, low-blast-radius screens first — back-office address capture, an admin-side store pin editor, ops-configured service points. Do not lead with anything customer-facing or revenue-critical, where a single-maintainer dependency is a bad bet.

When to Consider This Package

Adopt (as vendored/forked code) when:

• Filament v3 is your pinned admin stack and there is no v4 migration in the next two quarters.
• The requirement is strictly a single point on a form — pick a location, store coordinates, done.
• The consumer is an internal admin user, so a rendering bug or a dead tile provider is a support ticket rather than a customer-visible outage.
• You have an exit path: the field is isolated behind your own Filament form component or a thin wrapper, so replacing it with a Mapbox/Google implementation is a scoped task.
• Someone owns tile-provider keys and terms (this is true of any map, package or not) and you have confirmed which provider the widget uses and its licensing/attribution requirements.
• You are willing to fork it into your own VCS and accept maintenance, since upstream signals are weak.

Look elsewhere — or build the 2–5 day field yourself — when:

• The admin is on or moving to Filament v4; there is no evidence of v4 support here, and the last release predates it.
• You need address search / geocoding autocomplete, reverse geocoding, or address normalization. This is a pin picker; address-to-coordinate is a separate integration (Google Places, Mapbox, Nominatim) and a separate cost, quota, and privacy review.
• You need polygons, polylines, multiple points, or route stops. Point-only is a hard functional ceiling.
• You need geospatial querying at scale — proximity search over large datasets belongs in PostGIS or a spatial index, not in the widget layer.
• The map is customer-facing, or the feature sits on a revenue-critical path with no fallback.
• You require documented accessibility, i18n, or test coverage guarantees; nothing here evidences them.

Explicit verification gaps (treat as gates before commitment):

• 0 stars, a single release, no visible adoption. Popularity is a weak signal, but zero adoption means zero field-testing — expect to find the rough edges yourself.
• No release since 2024-09-02; maintenance cadence is unproven.
• Documentation is a README-level description only — no API reference, no screenshots, no supported-versions matrix.
• License is MIT, which is compatible; that is the one clean signal.
• Engineering must confirm: supported Filament/PHP/Laravel constraints in composer.json, tile provider and its key/attribution terms, whether JS assets are published and versioned, and whether the field's stored value shape fits your existing geo columns.

Bottom line: This is a trial-and-fork candidate for a low-stakes internal form field, not a platform-standard dependency. Budget a one-day spike; if the spike is clean, vendor it and move on. If it is not, the fallback (custom Leaflet field) is small enough that this is never a blocking decision.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a small feature — letting back-office staff drop a pin on a map and save the coordinates — that would otherwise cost an engineering sprint plus ongoing ownership of mapping JavaScript. There is a small open-source plugin that does exactly this for our admin framework, under a permissive MIT license. The catch is that it is early-stage: a single release, no visible user base, and no published support for the newest version of our admin framework. So the recommendation is deliberately modest: pilot it on one internal screen, and if it works, take a copy into our own codebase so we control it. Total exposure is roughly a day of engineering to evaluate, against a build we would otherwise own forever. If the evaluation fails, we fall back to building the same small field ourselves — the decision does not put the roadmap at risk either way.

To engineering (the ask): Timebox a one-day spike. Confirm from composer.json that Filament v3 and our PHP/Laravel versions are supported, install it, and stand up a single form that saves lat/lng into decimal columns. Report back on four things: (1) which tile provider it uses and what API key and attribution obligations that creates; (2) whether the published JS/CSS assets are versioned and cache-safe; (3) whether the field value binding is clean enough to sit behind our own wrapper component; (4) how much of the code we would have to own if we forked it. If the answer on (1) or (2) is uncomfortable, or if a Filament v4 upgrade is already on next quarter's plan, stop and we build the Leaflet field in-house instead — that is an acceptable outcome, not a failure. Do not standardize this across other admin panels until the spike reports back.