Gmap Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — and the verdict is "borrow the design." At 19 stars, 0 dependents, and a [DEVEL] stability flag, this is not a procurement candidate on any axis: no vendor, no support contract, no community, no patch path. The decision it actually supports is cheaper — read the source as a reference design for the domain model (coordinate value objects, map configuration objects, a geocoder service wrapper) and reimplement roughly 200 lines in-house. That is a defensible single-sprint scope with full ownership.

• Feature scoping for maps and geo functionality. The bundle's scope forces the right PM question: what actually belongs on the server? Map rendering, markers, and interactions are client-side concerns (Google Maps JavaScript API); only geocoding, distance math, and persistence justify backend code. A server-side "map manager" abstraction adds a dependency layer without adding capability — a useful argument for keeping the map feature thin in our own backlog.

• Platform roadmap and framework-upgrade routing. This is a Symfony 2 bundle, not a Laravel package, and Symfony 2 has been end-of-life for years. Any request to "add maps" that surfaces this package should be routed into the framework-upgrade backlog, not the feature backlog. The mapping request is the symptom; the EOL framework (and the Symfony-to-Laravel architectural mismatch) is the risk. On a Laravel codebase the answer is unambiguous: no adapter layer, no parallel kernel — build the integration natively or not at all.

• Prioritization of a geo capability gap. The relatively high opportunity score (0.76) against a low package score (1.20) is the signal worth reading: demand for a maintained, modern framework map integration is real and unmet. That justifies a time-boxed spike to validate whether our own geo needs recur across multiple squads and surfaces — not an adoption decision.

• Prototype vs. production gating. The legitimate use case is narrow but real: internal admin dashboards, back-office pin pickers, and demo builds where a map is a convenience and a broken tile is not a customer-facing incident. This package can inform a throwaway prototype; it should not cross the production gate.

• Supply-chain and dependency-governance policy. Zero dependents means zero downstream pressure to patch. Every future dependency request of this shape — abandoned, unmaintained, no test or CI signal — should be evaluated against the same bar: who owns the fix when the upstream provider changes its API terms? Answering "we do, forever" is the tell.

When to Consider This Package

Adopt (or, more accurately, fork and vendor) only when all of the following hold:

• The application is genuinely pinned to Symfony 2.x with no upgrade path in the next 12+ months — and this package is already in composer.json.
• The map surface is internal — admin tooling, ops dashboards, one-off visualizations — with no accessibility, SLA, or uptime commitments attached.
• You have accepted ownership explicitly: someone on the team will fork it, pin the Google Maps API version, and handle API key and billing configuration themselves.
• There is no requirement for provider abstraction (Mapbox, OpenStreetMap, self-hosted tiles) now or anywhere on the foreseeable roadmap.
• You have verified the emitted JavaScript targets the current Google Maps API. If the output references GMap2, GLatLng, or GClientGeocoder, it is on the retired v2 API and the bundle is functionally dead — plan a replacement, not a patch.

Look elsewhere — or build directly — when any of these are true:

• Any modern Symfony version (5/6/7) or any Laravel application. This targets Symfony 2 conventions and will not fit a modern service container without a rewrite that exceeds the cost of writing the integration yourself. For Laravel specifically there is no compatibility layer: Symfony bundles, its DI container, its configuration tree, and Twig do not map onto service providers, Laravel's container, config repositories, and Blade. The porting effort is the build.
• Customer-facing surfaces. Google Maps' JavaScript API now requires key management, billing accounts, quota controls, and a privacy/consent review. A [DEVEL]-flagged wrapper gives you none of that governance.
• Security or compliance review is in scope. A lone maintainer on an abandoned bundle is an unmanaged supply-chain risk you would have to absorb entirely.
• You need testability. Direct coupling to a third-party map SDK makes CI brittle; a thin in-house adapter with a mocked geocoder is cheaper than retrofitting test seams into someone else's bundle.
• You need provider portability or cost control. Maps pricing and terms change; an abstraction we own is the only reliable hedge.
• Composer health matters. PHP 5.x-era constraints will conflict with modern Laravel and PHP 8.x requirements, blocking unrelated upgrades — a hidden tax on the whole product roadmap.

How to Pitch It (Stakeholders)

Recommendation: do not adopt as a dependency. Fund a small in-house integration instead.

jfsimon/gmap-bundle is a development-status Symfony 2 bundle — not a Laravel package — last relevant to a framework that has been end-of-life for years. It has 19 stars and no dependent packages, meaning no community, no downstream users surfacing bugs, and no realistic path to a security patch. The total cost of ownership (fork, maintain, track the Google Maps API surface, manage keys and billing) exceeds the cost of writing the integration ourselves, measured in days, not quarters.

For executives: the mapping capability is cheap to deliver; the dependency is the expensive part. We recommend a thin integration with the Google Maps JavaScript API for rendering plus a small server-side geocoding service — roughly one sprint, fully owned, no third-party maintenance exposure, and no framework-migration dead end. The one genuinely valuable signal here is market-level: demand for a maintained, modern map integration is real and unmet. That is an argument for a scoped internal build, not for adopting an abandoned package. The risk framing is simple: adopting this would add a dependency we can never upgrade and can never get patched.

For engineering: treat the repository as a design reference, not a dependency. Its domain shape — coordinates, map configuration, geocoder wrapper — is a reasonable starting sketch. Reimplement it behind our own interface so we can swap providers, mock it in tests, and keep API keys and quota controls in our configuration layer. On Laravel, use the Google Maps JavaScript API directly in Blade for rendering and direct HTTP calls (Guzzle) to Google Maps Web Services for server-side work; skip the Symfony bridge entirely. If a legacy Symfony 2 surface genuinely needs a map before the framework upgrade lands, fork and vendor it explicitly, tag it internal-only, wrap the Twig helper in a single partial so replacement touches one file, and log the debt against the upgrade epic.