Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Google Map Form Type Bundle Laravel Package

krixer/google-map-form-type-bundle

A Symfony bundle that provides a Google Maps form type for selecting and storing geographic coordinates directly in forms. It adds an interactive map picker with configurable options, making location input easier in admin and user interfaces.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Location-capture UX (feature scope). This bundle is a reference pattern, not a product: a Symfony form type + Twig template that renders a Google Map with a draggable marker and binds the pin to hidden latitude/longitude fields. It answers the question "should 'set coordinates' be a text box or a map picker?" for any feature involving store locators, delivery-radius pricing, geofenced content, property listings, field-service dispatch, or site/asset registration.
  • Build vs buy for a commodity control. Signals here are decisive: 9 stars, 0 dependents, single release stream ending March 2021, opportunity score ~32. This is not a market. The realistic "buy" is "vendor a 2014-era snippet or wrap a JS map library yourself." In-house cost for a competent Symfony developer: roughly 0.5–2 days.
  • Data-quality decisions. Free-text lat/lng input produces swapped signs, transposed coordinates, and out-of-range values — a recurring source of bad geocodes, broken radius queries, and support tickets. A map picker converts that bug class into a UI affordance. This is quantifiable (invalid-coordinate rate, geocode failure rate) and is the strongest product argument for the widget, independent of which implementation you choose.
  • Platform decision — important: despite the "Laravel/PHP package" framing, this is a Symfony bundle. If the codebase is Laravel, it is a non-option; the decision becomes "which JS map component do we wrap in a Blade/Livewire/Inertia component?"
  • Dependency-risk decisions. MIT license permits forking. Zero dependents means no ecosystem pressure to keep it patched — you inherit 100% of maintenance. Treat as a code sample, not a dependency.

When to Consider This Package

Consider only when all of the following hold:

  • The application is Symfony (not Laravel) and already uses Symfony Forms, so the bundle mounts as a custom form type with minimal glue.
  • The Symfony version is old enough to match its 2021-era release; Symfony 5.4+/6+/7 compatibility is unverified and unlikely.
  • The use case is an internal/admin coordinate picker where degraded UX is acceptable.
  • You have a Google Maps JS API key and have accepted its billing and terms.
  • You are willing to fork, pin, and own security and compatibility going forward.

Look elsewhere when any of these hold:

  • Laravel, framework-agnostic PHP, or a JS-heavy front end — use Leaflet/MapLibre/Mapbox GL or a maintained Google Maps wrapper in your own JS layer.
  • You need geocoding, reverse geocoding, autocomplete, or routing. This bundle only writes lat/lng from a pin; it does not resolve addresses. That is a separate service decision (and cost line).
  • You need modern Symfony/PHP 8.1+ support, automated tests, or a maintained dependency with a security response path.
  • You need touch/mobile-first behavior, keyboard accessibility, or i18n of the map UI.
  • You want to avoid a per-map-load paid dependency — an open tile provider may be the better cost and product decision.
  • You need clustering, polygons, multi-marker, or drawing tools — out of scope for a form type.

How to Pitch It (Stakeholders)

Executives: "There's an existing open-source widget (MIT) that turns a latitude/longitude text field into a clickable map. It's Symfony-only, last released in 2021, and has essentially no user base — so we should not adopt it as a dependency. It's useful as a reference: reimplementing the equivalent is about a day of engineering and avoids inheriting an unmaintained vendor. Recommendation: build the picker in-house over a maintained map library; use this package as a spec, not a dependency."

Engineering: "Symfony form type + Twig template that renders a Google Map with a draggable marker and binds lat/lng. Not Laravel-compatible. Last release 2021, no meaningful maintainer base, zero dependents, no test or CI signal. Use it as a reference implementation. Build a thin wrapper over Leaflet (+ OSM tiles, zero marginal cost) or the Google Maps JS SDK, keep validation server-side (required pin, lat −90..90, lng −180..180), and budget 1–2 days. If we choose Google, add an API key and a billing line item to the plan."

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package