Google Map Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the mismatch is structural rather than cosmetic. Despite being filed under a PHP/Laravel package listing, lendable/google-map-bundle is a Symfony2 bundle: its public surface is a Bundle subclass plus a DI extension, a compiler pass, and Twig templates. Laravel has no bundle registration, compiler passes, or services.yml semantics, so none of the package's entry points can be invoked from a Laravel app. The actual domain logic lives in the upstream egeloen/ivory-google-map library, which is framework-agnostic — the bundle is only glue. That means the adoptable artifact is the library, not the package we are evaluating, and the library is itself abandoned.

Integration feasibility — feasible only as a fork-and-strip exercise. A Laravel integration would require: composer-installing (or vendoring) the underlying map library, replacing Symfony's container/config with a Laravel service provider and a published config file, and replacing the Twig templates with a Blade component or a JSON payload consumed by a JS component. The value delivered is a fluent PHP builder that serializes a map definition into HTML/JS — roughly a few hundred lines of value objects (Map, Marker, InfoWindow, Coordinate, Encoder). We would be paying integration cost for a thin serialization layer.

Technical risk — high and compounding.

• Archived, zero stars, zero dependents. No maintainer, no issue triage, no security response, no community corpus to search. Any defect is ours to fix.
• Dependency ceiling. Symfony 2.x has been EOL since 2018; the bundle's symfony/* constraints will conflict with the Symfony 6/7 components shipped inside Laravel 10/11. Expect composer resolution failure and a required replace/fork with widened constraints.
• PHP runtime drift. Code from 2016 targets PHP 5.6–7.0. Running it on PHP 8.2+ risks removed/deprecated constructs (each(), dynamic properties, non-nullable implicit conversions) that surface as fatals at runtime, not at install time.
• Google Maps API contract drift. Google's JS API has required an API key since mid-2016 and a billing-enabled project since 2018. Output generated by a pre-2016 renderer will typically produce the degraded "for development purposes only" map, or fail outright. This is a functional break, not a deprecation warning.
• Twig coupling. Default rendering paths assume Twig; Laravel ships Blade only.

Key questions for the requesting team

1. What is the actual requirement — server-side map markup generation, or just "show a map with markers"? For most Laravel apps the latter is satisfied by a Blade partial plus the Maps JS API directly.
2. Do we need PHP-side map objects at all, or would GeoJSON emitted from our own controllers be sufficient and more portable?
3. What is our minimum PHP version and Laravel major? That single answer likely determines whether the library installs at all.
4. Who owns ongoing maintenance of a fork, and is that budgeted?
5. Are there licensing/attribution or GCP billing considerations for the Maps key we'd use?

Recommendation: do not adopt as a dependency. Use it as a reference implementation for the object model, and build the ~200-line Blade/JS component in-house if server-side map composition is genuinely required.

Integration Approach

Stack fit. The bundle's stated target (Symfony2) and our target (Laravel) share only the PHP language. The realistic fit is architectural pattern reuse, not package reuse: the Ivory builder API is a reasonable prior art for how to model map layers, markers, and encoders.

Migration path (if we proceed)

1. Vendor, don't install. Copy the handful of value objects we need from egeloen/ivory-google-map into app/Support/Map/ (or a private composer path repo) so we control PHP-version compatibility and can delete Symfony-only code paths.
2. Replace the container glue. One GoogleMapServiceProvider registering the builder as a singleton, plus a config/google-map.php holding the API key, default center/zoom, and map ID.
3. Replace Twig with Blade. A <x-google-map :config="$map" /> component that emits a container div and an inline JSON config block; all rendering moves to a small vanilla-JS or Alpine wrapper against the current Maps JS API.
4. Drop the encoder indirection unless we specifically need address→coordinate geocoding server-side, in which case call the Geocoding API from a queued job and cache results — never inline in a request.

Compatibility gates (spike before committing)

• composer require the upstream library against our PHP/Laravel matrix; record the exact failure mode.
• Render a single map with a valid key on the target runtime.
• Confirm the serialized output matches the current Maps JS API (constructor options, mapId for vector maps, marker API — google.maps.Marker is itself deprecated in favor of AdvancedMarkerElement).

Sequencing. Two-day timeboxed spike → go/no-go. The fallback (build the component in-house against a GeoJSON contract) should be scoped in parallel, because it is very likely to be the cheaper path and it removes the abandoned-dependency exposure entirely.

Operational Impact

Maintenance. Full ownership transfer to us. The repo is archived — upstream will not accept PRs, cut releases, or patch CVEs. Every future PHP upgrade, Laravel upgrade, or Google API change is an internal ticket. There is no version to pin to; we pin to a commit hash and inherit the burden of reading it.

Support. Zero stars and zero dependents means effectively zero external knowledge base: no StackOverflow answers, no blog posts, no maintainer to escalate to. Onboarding depends entirely on the sibling library's README, which is itself stale.

Scaling. Server-side cost is negligible — the library builds strings and arrays; it is not a runtime hotspot. The real scaling surface is client-side and commercial: Maps JS API loads are billed against our GCP project, with per-key quotas. We must treat the API key as a budgeted, monitored resource with HTTP-referrer restrictions and hard quota caps, otherwise a traffic spike becomes an invoice event. Any server-side geocoding should be cached aggressively.

Failure modes to instrument for

• Silent visual degradation — missing/invalid key or unbilled project renders a watermarked map without throwing. Needs a smoke test or synthetic check, not just error monitoring.
• Hard fatal on PHP upgrade — surfaces at first map render, typically in staging or later. Mitigate with a render test in CI.
• JS API drift — Google changes marker/overlay APIs; serialized output becomes invalid with no server-side error. Mitigate by owning the client wrapper.
• Composer deadlock — Symfony constraint conflict blocks unrelated dependency upgrades across the app. This is the highest-probability operational incident and argues strongly for vendoring over requiring.

Ramp-up. Conceptually simple: a mid-level developer can absorb the object model in a day and complete a port in roughly one to two days, provided they are comfortable with the Maps JS API itself. The cost is not learning the library — it is the permanent tail of owning unmaintained code for a feature that has a well-supported, framework-native alternative.