Google Maps Bundle Laravel Package

Product Decisions This Supports

• Framing the "maps features" build-vs-buy question, not answering it. The only decision this package genuinely informs is how much map functionality we own. It demonstrates the scope of a typical first-pass wrapper (geocoding, static maps, distance/directions helpers) — useful as a checklist of what a maps feature actually needs, not as the implementation.
• Vendor-abstraction strategy. It's a cautionary data point for the "should we wrap Google Maps behind our own interface?" debate. A third-party wrapper with 1 star, 0 dependents, and no release since 2018 is exactly the dependency risk that argues for either (a) the official googlemaps/google-maps-services-php client behind a thin first-party adapter, or (b) no wrapper at all.
• Framework-fit validation for the roadmap. The package is a Symfony bundle, not a Laravel package. If this surfaced in a Laravel evaluation backlog, the correct product decision is to close the ticket: adopting it means writing and owning a Laravel service-provider bridge around a Symfony DI extension — custom glue code for zero upstream support.
• "Opportunity" scores should not drive roadmap. The 9.65 opportunity score is an artifact of near-zero adoption (low installs inflate headroom metrics), not a signal of latent demand or quality. Worth stating explicitly so it doesn't get cited in a prioritization deck.
• API surface currency check. Anything built on a 2018-era Google Maps wrapper predates the Routes API consolidation, current Places API tiers, and multiple pricing/field-mask changes. This supports a standing decision: no maps dependency older than the current Google pricing model.

When to Consider This Package

Adopt only if all of the following hold:

• You are maintaining an existing Symfony application (roughly Symfony 3/4 era) that already depends on this bundle, and removing it is a larger change than keeping it.
• The maps usage is genuinely peripheral and read-only — a static map image, a latitude/longitude lookup — with no billing exposure and no user-facing correctness requirement.
• You have read the source and confirmed which Google endpoints and parameters it calls, because the README-level description ("some Google Maps functions") is not a specification.
• You accept that you own all maintenance: MIT license permits forking, but there is no upstream, no issue response, and no security patch path.

Look elsewhere — decisively — if:

• You are on Laravel. There is no package here, only a bundle to bridge. The cost/benefit is negative before you write a line of code.
• You need anything current: Routes API, Places API (New), field masks, per-request cost control, or async/batch geocoding.
• You need a support contract, security disclosure process, or any SLA. None exist.
• Your maps feature is customer-facing or revenue-adjacent — geocoding failures and stale distance calculations are quiet, expensive bugs.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Treat this package as a reference example of a maps wrapper, not a dependency.

For executives (one paragraph): We evaluated a third-party Google Maps integration for PHP. It's a Symfony component with a single star, no downstream users, and no release in over seven years — and it doesn't fit our Laravel stack without custom glue code we'd own permanently. Google's Maps APIs and pricing have changed substantially since 2018, so the integration would likely need rework regardless. Recommendation: build the maps capability on Google's officially supported PHP client behind a small first-party interface, sized at roughly one to two engineer-weeks for our initial use cases, and keep the vendor boundary thin enough that switching providers stays a configuration change rather than a rewrite. This avoids inheriting an unmaintained dependency in a billing-sensitive area.

For engineering (the substance): The bundle is pre-Routes-API, pre-Places-New, and predates the current pay-as-you-go model — expect deprecated parameters and no field-mask cost controls. Zero dependents means no community-found bug reports; we'd be the first to hit every edge case. Preferred path: official googlemaps/google-maps-services-php client, wrapped in a MapsClient interface of our own with three or four methods (geocode, reverse geocode, distance/route, static map). That gives us unit-testable seams, a place to enforce quota and caching, and a clean swap if we ever move to Mapbox or self-hosted tiles. If someone wants the bundle's helper ergonomics, copy the relevant ideas — the MIT license allows it — rather than taking the dependency.

Decision owner and next step: Engineering to confirm the actual maps requirements (which of geocode / route / static map / places are truly needed), then scope the thin adapter. Close the package-evaluation ticket with the framework-mismatch and staleness rationale recorded, so it isn't re-raised.