ivory/google-map-bundle
Ivory Google Map Bundle integrates Google Maps into Symfony applications, providing services and Twig helpers to render maps, markers, info windows, and controls, with configurable map options and geocoding support.
Architecture fit — poor to moderate. ivory/google-map-bundle is a Symfony bundle, not a framework-agnostic PHP package. It targets symfony/http-kernel bundle registration, the Symfony Config component tree (config/packages/ivory_google_map.yaml), the service container, and a Twig extension for rendering. Laravel has no bundle concept, no bundles.php, and no PackageManifest discovery for this package type. There is no Laravel service provider, no Blade directive, and no published config stub. Adopting this package as-is in a Laravel app is not supported and should not be planned for.
What is actually reusable. The package is a thin rendering layer over the framework-agnostic core library ivory/google-map, which is the piece with genuine substance: a Map object model with markers, info windows, controls, overlays, and JSON serialization of the map configuration. That core depends on symfony/options-resolver and symfony/serializer (both Composer-installable and non-conflicting alongside Laravel's existing Symfony components), so it can be consumed directly inside a Laravel service provider without the bundle. The bundle itself adds value only in two areas we would have to rewrite anyway: Twig helpers and Symfony config wiring.
Integration feasibility. A Laravel path exists but is a port, not an install: bind the core library in a service provider, load the API key from config/google-map.php (sourced from services.google_maps.key), and expose rendering via a Blade component (<x-google-map :map="$map" />) or a @googleMap directive replacing the Twig functions. The bundle's Twig extension and asset-inclusion helpers must be reimplemented. Realistically 2–4 engineer-days for a proof of concept, more if the map output needs CSP nonces or consent gating.
Technical risk — high. Stars (9) and dependents (0) indicate essentially no production adoption, and the package sits in the Ivory ecosystem, which has been largely dormant. Release 6.1.2 (a patch, with no described functional change) does confirm the maintainer is still active, but the release note itself — "should work fine even pipeline is failing on php 8.4" — is a negative quality signal, not a reassuring one. It tells us: (a) upstream CI is red on the current PHP minor, (b) the package is being shipped with an unverified claim of compatibility, and (c) the project currently has no automated regression signal on PHP 8.4. For a Laravel app running 8.4, "should work fine" is an assertion we would have to validate ourselves, and any future PHP minor bump inherits the same gap. The bus factor remains one. Additional pre-existing risks: the library emits legacy google.maps.Marker output rather than AdvancedMarkerElement, which Google has deprecated — verify against your target rendering path. There is also no built-in CSP nonce support and no consent gating before the Maps script loads, which is a compliance problem for EU traffic and a security-review flag for most enterprises.
Key questions.
google.maps.Marker, and does that matter for our 12–24 month horizon?bresam stops releasing — do we have appetite for a vendored fork?Stack fit. Weak at the bundle layer, acceptable at the core-library layer. The pragmatic shape is: install ivory/google-map only, skip ivory/google-map-bundle entirely, and build a small first-party adapter.
Migration path.
ivory/google-map (core) with an exact pin, not a caret constraint. Do not require the bundle or its Twig extension.GoogleMapServiceProvider binding a configured MapFactory singleton; publish config/google-map.php with key, language, region, libraries, and a render_mode flag.@googleMapScript stack push using @push('scripts') and Vite, loading the JS API with loading=async and a callback rather than a blocking <script>.MapRenderer interface so the underlying library is swappable — this is the exit hatch if the dependency proves unmaintained.Compatibility. The core library's OptionsResolver/Serializer dependencies coexist with Laravel's Symfony components, but pin versions and verify no conflict with the Laravel major in use. PHP version constraints deserve explicit attention following 6.1.2: the release note concedes upstream's pipeline fails on PHP 8.4, so do not treat a green composer update as evidence of compatibility — run the package's own test surface (or a targeted rendering smoke test) on our runtime. The bundle's Twig dependency is moot once the bundle is dropped, which removes the largest incompatibility.
Sequencing. (1) Spike against a single low-risk page — one static map with markers — on our actual PHP version. (2) Instrument cost and load-time impact. (3) Decide build-vs-adopt with real data. (4) Only then wire into the broader component library. Do not sequence this ahead of higher-opportunity work: at opportunity score 36.35 and zero dependents, this is a convenience library, not a platform bet. Nothing in 6.1.2 changes that ordering or the risk-adjusted value.
Build-vs-adopt recommendation. Given that the reusable surface is a serializable map model, that a Laravel-native Blade component wrapping the Maps JS API is small and fully owned, and that 6.1.2 arrives with a red pipeline on the current PHP minor, I would lean more firmly toward building the thin wrapper and treating ivory/google-map as an optional internal helper — not a dependency the product depends on. The marginal benefit of the core library is now offset by an explicit test-yourself compatibility burden.
Maintenance. The bundle is effectively single-maintainer with no downstream dependents, so we inherit the maintenance burden for the Laravel adapter and for any upstream gaps. Release 6.1.2 confirms activity but also confirms we cannot use upstream CI as a canary — the PHP 8.4 pipeline is failing and shipping anyway, which means breakage on a future PHP minor would reach us with the same "should work fine" framing. Budget for a vendored fork or a patches entry in composer.json if upstream stalls. Version-pinning discipline is required; floating constraints against a low-activity package is an avoidable risk.
Support. No Laravel community, no Laravel-oriented documentation, no Slack/Discourse presence. Issues route to a Symfony-oriented repo where our integration shape is not the target use case, and where the maintainer is currently publishing ahead of a green build. Internal documentation for the adapter becomes mandatory, not optional.
Scaling. Technically the package is a client-side renderer, so server scaling is a non-issue. The real scaling axis is Google Maps Platform billing: under the 2025 Essentials/Pro/Enterprise model, Dynamic Maps is an Essentials SKU with a monthly free call allowance, and every map load counts. A naive implementation that renders maps in list views or on every page load will surface as a line-item cost spike, not a latency problem. Gate map renders behind user intent (click-to-load) on high-traffic pages and cache any server-side geocoding or place data.
Failure modes.
Ramp-up. PHP engineers will grasp the core Map API in a few hours; the real cost is the Blade/Twig port and the service-provider wiring, roughly 2–4 days including tests. Add a half-day for PHP-version compatibility validation following 6.1.2. The hidden ramp-up is Google Maps Platform specifics — API key restrictions, CSP, consent gating, and quota modeling — which is knowledge the team will have to acquire regardless of whether this package is adopted.
How can I help you explore Laravel packages today?