Google Map Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on map rendering: buy nothing. The core capability here — drop a Google Maps JS v3 canvas into a page, plot markers from stored lat/lng, open an info window — is roughly 50 lines of JavaScript plus a small view partial in Laravel (Blade component) or a Twig template in Symfony. A server-side bundle wrapping that JS buys abstraction, not capability, and every abstraction layer over the Maps JS API becomes a liability the moment Google changes the API surface.
• Deprecation / dependency-audit decision: reject. Archived repo, zero releases since 2016-07-18, zero stars, zero dependents. Zero dependents is the loudest signal: no community has stress-tested this against PHP 7.4/8.x, Symfony 4/5/6+, or Google's 2018 billing-and-API-key overhaul. Adoption means we own the fork on day one.
• Platform scoping correction. The ticket frames this as a "Laravel/PHP package"; it is a Symfony2 bundle (*Bundle, getContainer-era conventions). It is not installable into a Laravel app, and it is not compatible with modern Symfony either. If this came from a shortlist, the shortlist has a taxonomy bug worth fixing before it costs engineering a sprint.
• Roadmap input: map features should be scoped as front-end work. If the roadmap has "store locator," "site map," or "delivery-zone visualisation," budget it as a JS/spatial-data task (markers from an API endpoint, clustering, viewport bounds queries), not as a PHP dependency evaluation. That reframing removes this class of package from consideration entirely.
• Policy artifact. This is a good worked example for a standing rule: no dependency that is archived, unmaintained for 3+ major PHP versions, or has zero dependents. Adopting one is a permanent maintenance tax disguised as a time saving.

When to Consider This Package

Adoption criteria — this package meets none of them:

• Legacy Symfony 2.x application, frozen, no upgrade path. The only scenario where pulling this in is defensible is an app already pinned to Symfony 2.3–2.8, already on PHP 5.x, and where the map is a cosmetic, non-critical page. Even then, prefer an unmaintained-but-simpler path: include the Maps JS directly.
• You need server-side map object modelling (marker collections, bounds, encoded polylines) rather than map rendering. That was the value of the underlying egeloen/ivory-google-map library — which is also abandoned and superseded. Don't resurrect it.

Look elsewhere (or build thin) when:

• Laravel 9/10/11, Symfony 6/7, or PHP 8.1+. Hard stop — incompatible.
• You need geocoding, distance matrix, places autocomplete, or static maps. Call Google's HTTP APIs directly from a queued job or a small service class; you want retry, caching, and cost control, not a view-layer bundle.
• You need markers driven by our own data. A JSON endpoint + a Blade/Twig partial is less code than wiring a bundle, and it's code we can read.
• Cost governance matters. Google Maps moved to pay-as-you-go with mandatory API keys in 2018. Any wrapper written before that predates the billing model we actually operate under; the config surface will be wrong.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Close the ticket.

To engineering leadership: this is an archived Symfony2 bundle, last released in 2016, with zero stars and zero dependents. It predates PHP 7, Symfony 3, and Google's 2018 Maps billing model. Making it work in a current Laravel or Symfony codebase is a fork-and-own project, not an install — and what we'd be maintaining is a thin wrapper around JavaScript we'd write anyway in under a day.

To executives: the feature we actually want (a map with our locations on it) is a small, well-understood front-end task. This package would convert a one-day build into a standing maintenance obligation on a component nobody else in the world depends on — no security patches, no compatibility fixes, no upstream. The cheapest and safest path is to build the small thing ourselves and call Google's APIs directly, which also gives us the API-key and spend controls we need.

Ask: remove this from the shortlist, and adopt a short dependency-admission checklist (maintained within the last 12 months, non-zero dependents, supports our PHP and framework versions, compatible with current third-party billing/API terms) so shortlists stop surfacing dead code.