- Can I install mkebza/google-maps-bundle in a Laravel application?
- Not practically. It is a Symfony bundle built around Bundle subclasses, DependencyInjection extensions, and YAML/XML service definitions, and Laravel has no bundle loader to register any of that. There is no shared extension point with ServiceProvider, Facade, or config publishing, so an install-and-go setup is not achievable. At best you can read the source and lift the plain-PHP Google Maps logic out of the Symfony wiring.
- Does this package support Laravel 10 or Laravel 11?
- No. The project is a Symfony bundle with a last release from December 2018, which pins symfony/* components to the 3.x/4.x era. Laravel 10 and 11 require Symfony 6 and 7 components, so the constraint graphs are mutually exclusive. Composer will either refuse to resolve the package or try to downgrade your framework, which is a hard stop rather than a warning.
- What does the GoogleMapsBundle actually provide — server-side API calls or front-end JavaScript maps?
- The overview only promises configuration and helpers for embedding maps and working with Google Maps services, so you must audit the source to know which it is. If it wraps HTTP calls such as Geocoding, Places, Directions, or Distance Matrix, that logic is portable to Laravel's HTTP client in hours. If it mainly emits JavaScript, assets, or templating helpers, it is close to worthless under Blade and Vite and should be skipped entirely.
- Is mkebza/google-maps-bundle still maintained?
- No. The last release was 2018-12-13, there is a single maintainer, roughly one star, and zero dependents. There is no security response capability, so a disclosed vulnerability would simply go unpatched. Treat it as a reference implementation from a past era, not a dependency you plan to support long term.
- Why does Composer fail to resolve this package in a Laravel project?
- Because its transitive dependency tree forces Symfony 3.x or 4.x packages, and modern Laravel pins Symfony 6 or 7 for components like the HTTP foundation and console. Composer's solver treats that as a conflict, so resolution fails or proposes a framework downgrade you should never accept. Run composer why-not mkebza/google-maps-bundle to confirm the exact constraint before doing any further work.
- Does this package run on PHP 8.2 with Guzzle 7?
- It is PHP 7.x-era code with nullable typing, missing return types, and possibly deprecated functions, and it was written against Guzzle 5 or 6. That makes runtime failures on PHP 8.2 or newer likely rather than theoretical. If you extract the API layer, re-verify TLS, proxy, and JSON decoding behaviour under Guzzle 7, and re-run every call against current Google Maps Platform endpoints.
- How do I add Google Maps geocoding or Places to Laravel without this bundle?
- Build a thin wrapper over Laravel's HTTP client with a config-driven API key in config/google-maps.php, retry and timeout settings, and response DTOs so the vendor surface is one class deep. Bind it in a GoogleMapsServiceProvider and expose a facade only if the ergonomics justify it. This takes a day or two for the first endpoints and gives you code you actually control.
- How do I port the bundle's Google Maps logic into a Laravel service class?
- Clone the repository and enumerate the classes, separating Google API interactions from Symfony container and event-dispatcher wiring. Port the isolated calls into app/Services/GoogleMaps behind an interface using Http::retry and Http::timeout, and replace Symfony OptionsResolver usage with explicit validation or Laravel validation rules. Re-key any hardcoded endpoint URLs or legacy parameters and confirm response shapes, status codes, and error bodies against the live API.
- How should I test Google Maps integration in Laravel, and what about quotas in production?
- Use Http::fake with recorded fixtures so contract tests lock the response shape, then add one opt-in integration test against the real API keyed from the environment. For production, cache geocodes aggressively since address-to-lat/lng is highly cacheable, add rate limiting, and instrument quota usage so you notice pricing or restriction changes early. Google Maps Platform has changed pricing, key restriction enforcement, and signing requirements since 2018, so do not trust the bundle's assumptions.
- What are the maintained alternatives to this Symfony bundle for Laravel?
- The realistic options are a Guzzle- or Laravel HTTP-based Google Maps SDK consumed directly from a service provider, or a short in-house wrapper covering just the endpoints you need. The near-zero adoption of this package against a high opportunity score tells you whitespace exists for a well-maintained Laravel package, not that this artifact is validated. Pick whichever option keeps the vendor code one class deep and swappable.