Google Map Form Type Bundle Laravel Package

Technical Evaluation

Architecture fit — the framing is wrong. oh/google-map-form-type-bundle is a Symfony bundle, not a Laravel package. It provides a Symfony Form type (GoogleMapType) that renders a Google Map with a draggable marker and syncs the marker position into two form fields (latitude/longitude). There is no service provider, no config publishing, no Blade view, and no illuminate/* dependency. Under Laravel, the Laravel–Symfony Form bridge exists but is not a supported path for adding a bundle's Twig form theme to a Blade/Livewire stack. Net: on Laravel this is a reference implementation to port, not a dependency to install.

What is actually reusable. The durable value is small and mostly front-end: the JS glue that (a) initialises a map at a default lat/lng/zoom, (b) binds a draggable marker to two inputs, (c) updates inputs on dragend/click, and (d) handles the empty/partial-coordinate case. That is roughly 80–150 lines. The bundle wrapper around it is Symfony 2/3 ceremony.

Integration feasibility.

• Laravel (the stated target): low, as an install. High, as a port. Do not composer require this. Extract the JS, rebuild as a Blade component (optionally Alpine/Livewire), validate server-side with a FormRequest using numeric|between:-90,90 / between:-180,180 and an "either both or neither" rule.
• Symfony 5–7 (if that is the real target): low. The bundle predates Symfony 3's AbstractType::getName() removal, configureOptions() replacing setDefaultOptions(), Flex recipes, bundles.php, and Twig 2/3 form-theme changes. Expect a fork, not a version bump.

Technical risk.

• Abandonment. Last release 2016-07-21; 15 stars; 0 dependents. No CI, no tests, no security policy, single maintainer. Zero community vetting — you are the only QA.
• Google Maps JS API drift. The bundle predates the 2018 API-key-plus-billing-account requirement, and uses google.maps.Marker, deprecated in favour of AdvancedMarkerElement (which requires a Map ID). Expect the "For development purposes only" watermark or a console deprecation/error path on day one.
• Billing and consent exposure. A map embed is a billable Dynamic Maps load and a third-party request to Google — a GDPR/ePrivacy consideration in the EU that the bundle does nothing to gate.
• Modern front-end assumptions. No CSP nonce support, no shadow-DOM/web-component awareness, no touch-drag handling for AdvancedMarkerElement, no SSR/Inertia story.
• The 0.785 score is misleading for a TPM decision: it appears driven by opportunity/novelty, while stars, dependents, and release recency all point to a dead artifact.

Key questions.

1. Is the real target Laravel or Symfony? If Laravel, are we porting or is there a maintained alternative (googlemaps/maps-style JS wrappers, Leaflet, MapLibre, or the Google Maps Web Components)?
2. Do we already have a Maps JS API key with billing enabled, and a Map ID for AdvancedMarkerElement?
3. Is a map picker a hard requirement, or will address search + geocoding on the server (Places Autocomplete / Geocoding API) satisfy the user need with less client JS?
4. What is the consent/CSP posture in the target jurisdictions?
5. Do we need reverse geocoding (click → address), or only forward lat/lng capture? Only the latter is cheap.

Integration Approach

Stack fit. Not fit-for-purpose as a dependency on Laravel 10/11/12. Treat it as a design source: it encodes the correct field semantics (two numeric fields, map as an input affordance, marker as the source of truth on drag, inputs as source of truth on manual edit).

Migration path (recommended, Laravel).

1. Spike: run the bundle's Twig/JS in a throwaway Symfony or static page to confirm the interaction model and capture the exact JS.
2. Reimplement as <x-google-map-picker name="lat" lng-name="lng" :center="..." :zoom="..." /> with a Blade partial, a small vanilla JS or Alpine component, and the API key injected from config('services.google_maps.key').
3. Enforce server-side truth: normalize to decimal(10,7)/decimal(11,7); reject partial coordinates; treat the client as advisory only.
4. If the Symfony route is real: fork, bump composer.json to ^6.4|^7, replace getName()/setDefaultOptions(), migrate the Twig theme to a form_theme, add a Flex recipe-style bundles.php entry, and pin symfony/form: ^6.4|^7.

Compatibility checklist to verify before any fork effort.

• composer.json PHP constraint and Symfony range (likely ~2.3|~3.0, PHP ≥5.3).
• Twig 1.x template syntax and any Assetic references.
• AbstractType::getName() and setDefaultOptions() usage.
• Bundle class extending Bundle without getPath()/Flex conventions.
• Any hard-coded API key or script tag URL.

Sequencing. Spike (0.5d) → port JS to Blade/Alpine (1d) → key/config/CSP/consent wiring (0.5d) → validation + tests incl. empty-map and out-of-range cases (0.5–1d) → accessibility pass (keyboard marker movement, text-input fallback as the primary path) (0.5d). Budget 3–5 dev-days for a production-credible Laravel version; 1–2 days for an internal-only one.

Alternative to consider and price alongside. Leaflet or MapLibre + OSM tiles removes the API key, the billing relationship, and most of the consent complexity at the cost of geocoding quality. For a single lat/lng picker, this is frequently the better TPM call; Google earns its place only if you also want Places Autocomplete and Street View.

Operational Impact

Maintenance. You inherit 100% of it. There is no upstream to patch Google API deprecations, and the 2016 cutoff means the first breakage has already happened. Treat every future Google Maps JS API change as your ticket.

Support. None. No issue triage, no security advisories, no release cadence. Internally, designate an owner for the map component — it is a small but permanently owned surface.

Scaling.

• Cost: Dynamic Maps is billed per map load. A picker on a high-traffic create/edit form is a recurring line item you would not have with a static map or a self-hosted tile layer. Estimate map loads × monthly form renders before committing.
• Performance: the Maps JS SDK is a heavy third-party payload on a form page; defer-load it and lazy-init on focus/intersection.
• Correctness at scale: lat/lng precision must be pinned in the schema; floats in MySQL and JavaScript round-tripping will produce off-by-a-few-metres drift if left to defaults.

Failure modes to design for.

• Missing/invalid API key → grey "For development purposes only" map, silent user confusion.
• Quota exhaustion or billing lapse → blank map with a console error only.
• CSP or ad-blocker blocks maps.googleapis.com → the text inputs must remain fully usable; the map is an enhancement.
• Deprecated google.maps.Marker → marker may not render on the current API version.
• Empty state: form loaded with one coordinate, or none — the bundle's default-centre behaviour must be explicitly specified.
• Mobile/touch: drag-to-place is unreliable; pair it with a "use my location" button (Geolocation API) and a text fallback.
• Consent-gated jurisdictions: map must not load until consent, which means an interstitial placeholder.

Ramp-up. Low for any front-end-capable developer — the concept is a two-input map picker, not novel. The cost is not learning it; it is re-deriving the deprecated-API fixes and writing the tests the package never had. Allocate the ramp-up budget to the port and the Google API migration, not to reading this repo's docs (there are effectively none).