Google Map Form Type Bundle Laravel Package

Product Decisions This Supports

• Geo-capture UX in forms: the underlying capability — letting a user drop a pin on a map and storing latitude/longitude — is a recurring requirement in address management, store/asset locators, delivery zones, field-service job sites, and property listings. This package is a reference implementation of that pattern (a Symfony form type wrapping a Google Maps widget).
• Build vs. buy for map-input widgets: the honest read is that this is a buy-nothing decision. At 2 stars, 0 dependents, an archived repo, and a final release in July 2018, the package has no viable support surface. The decision it informs is "build the ~150-line form type ourselves" — the feature is small, well-understood, and tightly coupled to your own validation, geocoding, and API-key handling anyway.
• Vendor and API dependency exposure: adopting it ties a form field to the Google Maps JavaScript API, which has since moved to pay-per-load billing and mandatory API keys. That is a product-level cost and compliance decision (budget line, key management, privacy disclosures), not just a technical one.
• Stack-fit triage: despite the PHP/Laravel framing in the catalog, this is a Symfony bundle. It does not drop into Laravel without adaptation, which makes it a poor fit for the stated target stack and a signal that catalog metadata should not be treated as a compatibility guarantee.
• Roadmap hygiene: useful as a design reference for the "map + manual coordinate fallback + validation" interaction, and as a cautionary data point when scoring maintenance risk of niche UI packages.

When to Consider This Package

Consider it only under narrow conditions:

• You are maintaining a legacy Symfony 2.x/3.x application, cannot upgrade, and need a quick internal map input where accessibility and long-term maintenance are non-issues.
• You need a throwaway prototype or internal admin tool and are explicitly accepting unmaintained code with no security patching.
• You want to read the source as a pattern reference for implementing your own form type — not install it.
• Your team has already validated Symfony/Google Maps API compatibility and is prepared to fork and own the code.

Look elsewhere (or build) when:

• You are on Laravel, modern Symfony (5/6/7), or PHP 8+ — the bundle predates these and will not install or run cleanly.
• You need security patching, accessibility (WCAG) support, or vendor SLAs — none exist here.
• You require Google Maps API key/billing compliance, geocoding, autocomplete, or reverse geocoding — build on the current Google Maps JS API or a maintained alternative (Leaflet/MapLibre with OpenStreetMap avoids the billing and ToS surface entirely).
• You are planning beyond a single sprint; an archived dependency with zero dependents is an orphan you will own forever.

How to Pitch It (Stakeholders)

Executive summary: This is a small, abandoned open-source component that adds a click-a-map-to-set-coordinates field to web forms. It is not a strategic asset. It has two GitHub stars, no downstream users, no release since 2018, and has been archived by its author — meaning no security fixes, no compatibility updates, and no support. It is also built for Symfony, not our Laravel stack.

Recommendation: Do not adopt. The capability it provides is worth roughly one to two engineering days to implement in-house, giving us full control over Google Maps API costs, key management, validation, accessibility, and privacy disclosures. Building also removes a dead dependency from our supply chain and avoids the cost of eventually migrating off it.

What we take from it: the interaction pattern, not the code. If map-based location entry appears on the roadmap, treat it as a scoped, own-it-forever build item with an explicit decision on map provider (Google Maps with billing, or Leaflet/MapLibre to avoid per-load costs). Engineering can prototype against current APIs in a sprint; the abandoned bundle is not on the critical path.

Risk if ignored: low immediate risk given zero adoption, but adopting it would import an unpatched third-party dependency into a customer-facing form and anchor us to an outdated Google Maps integration.