Google Map Form Type Bundle Laravel Package

Technical Evaluation

The framework mismatch is the headline finding. Despite being surfaced against a Laravel/PHP package query, krixer/OhGoogleMapFormTypeBundle is a Symfony bundle, not a Laravel package. It depends on symfony/form, symfony/framework-bundle, the Symfony DI container, Twig bundle asset publishing (Resources/public), and bundle registration through config/bundles.php. None of that compiles into a Laravel application. The usable IP is roughly 150–250 lines: a AbstractType subclass exposing lat/lng children, a Twig template embedding the Maps JS API, and a small JS file that binds a marker drag to two hidden inputs. That is a reference implementation, not a dependency.

Architecture fit: poor for our stack, acceptable for a legacy Symfony app. If the consuming service is Symfony 4/5 with Twig and Doctrine, registration is genuinely trivial: enable the bundle, set the API key in bundle config, add the custom form type to an existing entity form, and lat/lng flow into the entity as floats. If the consumer is Laravel — the presumed context — the integration is a rewrite, and a short one. There is no adapter, bridge, or headless mode.

Integration feasibility: high effort relative to value. The package contributes no server-side logic of substance: no geocoding, no validation, no reverse lookup, no persistence layer, no coordinate normalization. It is a UI widget. A Laravel equivalent (Blade partial or Livewire/Alpine component + @vite asset + a maps config key) is a 1–3 day build that we would own outright and could target Mapbox or Leaflet instead of Google.

Technical risk: abandonment plus upstream API drift.

• Last release 2021-03-29, 9 stars, 0 dependents, no visible maintainer cadence. Effectively unmaintained; any fix becomes our fork.
• Targets Symfony 5-era form APIs. Symfony 6/7 compatibility with AbstractType signatures and option resolvers is unverified and would need a spike.
• Google Maps JS API has moved materially since 2021 — google.maps.Marker is deprecated in favor of AdvancedMarkerElement (which requires a Map ID), and the pricing/free-tier model has changed. The bundled JS likely uses the deprecated marker path.
• API key handling: bundle config places the key in application config and renders it into client-side JS. That is expected for Maps JS, but it needs HTTP-referrer restrictions and possibly a proxy for any server-side Geocoding calls — neither is addressed.

Key questions before any decision:

1. Which framework is the actual target service — Symfony or Laravel? (Everything downstream hinges on this.)
2. Is Google Maps a mandated provider, or is provider choice open? Leaflet + OSM removes per-load billing and vendor lock entirely.
3. Do we need pin-drop only, or address→coordinate geocoding and reverse geocoding? The package does neither.
4. What is the coordinate validation contract — bounds checking, nullability, precision, SRID? The package enforces none.
5. What is the expected map-load volume and the resulting billing exposure?

Assessment: do not adopt. Reference-implement. The 0.605 score and 32.19 opportunity score are consistent with what the code review shows: a small, single-maintainer, one-framework widget with no dependents. The correct TPM action is to mine it for the interaction pattern, not to take a dependency on it.

Integration Approach

Stack fit. In Symfony 4/5: native fit, ~30 minutes to first render. In Laravel 9–11: no fit; the bundle's service provider, Twig namespace registration, and asset-publish command have no Laravel analogues. Laravel's form layer (Blade, FormRequest, validation rules) is not Symfony Form, so the AbstractType cannot be reused as-is even as a library.

Recommended migration path — build, don't port. Treat the bundle as a design reference:

• One Blade partial or Livewire component rendering a map container plus two hidden/readonly inputs (lat, lng).
• One JS module behind Vite handling map init, marker placement, drag-sync, and initial state from the inputs.
• One config/maps.php entry for the key, wired through .env and never hardcoded.
• One FormRequest rule set: lat between -90/90, lng between -180/180, both required_with each other, numeric, fixed precision.

This gives us a component we can reuse across every admin form that needs a location, which the original does not offer across framework boundaries.

Compatibility checklist for the spike (half a day):

• Confirm target Symfony version and whether AbstractType::configureOptions signatures match the 2021 code.
• Confirm PHP 8.2/8.3 deprecation status.
• Confirm the bundled JS still functions against the current Maps JS API, or whether AdvancedMarkerElement + Map ID is required.
• Confirm CSP posture: maps.googleapis.com must be allowlisted for script, and maps.gstatic.com/fonts.googleapis.com for style/font as applicable.

Sequencing.

1. Decision gate: framework and map provider confirmed.
2. If Laravel: build the internal component (1–3 dev days), ship behind a feature flag on a single low-risk admin form.
3. Validate data quality — inspect saved coordinates for 0,0 and out-of-bounds values from the first week of use.
4. Roll out to remaining forms; add address geocoding as a separate, server-side concern only if the product requires it.
5. If Symfony and the app is already on Symfony 5: the bundle can be adopted short-term, but budget for a fork-and-vendor step, since upstream fixes cannot be assumed.

Operational Impact

Maintenance. Zero upstream maintenance expected. The project has one maintainer, no releases in four years, and no dependent packages — meaning no downstream pressure to keep it working. Any security or API-compat fix lands on us. Vendoring or forking converts this into an internal component with an internal owner, which is the honest accounting.

Support. No community to escalate to; issue response is not a service we can plan around. Support burden shifts entirely in-house, and the knowledge required (Google Maps JS API specifics) is not transferable from the package's documentation.

Scaling and cost. The binding constraint is not server load — it is Google Maps billing. Dynamic Maps loads are billed per request, with a monthly free allotment per SKU (10,000 at time of writing, subject to change). Every admin form render carrying a map is a billable event. On a high-traffic public-facing form this becomes a real line item; on internal admin tooling it is negligible. Two mitigations worth deciding early: lazy-load the map on focus/click rather than on page render, and restrict the API key by HTTP referrer. If form volume is public-scale, Leaflet + OSM is materially cheaper at the cost of geocoding quality.

Failure modes.

• Silent bad data. The most dangerous failure: if the API key is invalid, restricted, or the script is CSP-blocked, the map renders blank but the form still submits — often persisting 0,0 or nulls. There is no built-in guard. Mitigate with server-side bounds validation and a required rule that rejects 0,0 for real-world locations.
• No progressive enhancement. If JS fails, the user has no way to enter coordinates unless the underlying inputs are editable. Design the inputs to accept manual entry as the fallback.
• Deprecated marker API. Google's marker deprecation means the widget can degrade or warn unexpectedly without any code change on our side — an unowned upstream risk.
• Key leakage. The key is client-visible by design; without referrer restrictions it is exfiltratable and billable by third parties.
• Precision drift. No normalization to a fixed decimal scale means coordinates may round-trip inconsistently between DB column type and JS float.

Ramp-up. Conceptually low — the pattern is well understood and the code is small enough to read in an hour. But ramp-up on this artifact is wasted effort for a Laravel team: the Symfony-specific knowledge (bundle registration, Twig namespaces, asset publishing) does not transfer. The faster path is for one engineer to read the template and JS, then write the Laravel equivalent directly.

Bottom line. Low adoption risk only because it is trivially replaceable; unacceptably high ownership risk for a production dependency. Reference it, build 200 lines in-house, and spend the saved integration time on coordinate validation and API-key hygiene — the two things this package leaves entirely to the consumer.