Location Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for geo-entity handling. The package scopes a genuinely small capability: attaching a latitude/longitude pair (and usually a formatted address) to a domain record, plus a service call that turns an address into coordinates on write. That is a one-to-two-day build for a mid-level engineer, not a platform decision. Its value to a PM is as a checklist for what a minimal location feature needs — an embeddable value object, a geocoder integration point, a persistence mapping — not as a dependency.
• Roadmap scoping that separates the cheap part from the expensive part. Store finders, "near me" search, address capture on customer or venue records, delivery-zone assignment, and IP-to-city personalization all start from the same primitive. Reviewing this bundle helps you draw the line honestly: storing coordinates on an entity is cheap; geocoding provider contracts, rate limits, caching, cost control, and radius queries are the actual work. Scope and estimate the second part explicitly.
• Data model decisions that outlive any library. It pushes the right default: coordinates as a separate value object or cast pair rather than four loose columns scattered across tables, geocoding treated as a service-layer concern rather than something a controller does inline, and the display address stored separately from the coordinates. Adopt the model, not the code.
• Framework-agnosticism as a buying criterion. The bundle is Symfony-specific — a DI bundle wrapping services, Doctrine embeddables, and Symfony form types. On a Laravel surface there is no service provider, no config publishing, no Eloquent integration. This resolves the adoption question early: porting, not installing, which removes "buy (or adopt) from the table entirely.
• Dependency hygiene policy. Four stars, zero dependents, and no release since November 2020 is a concrete input for a standing rule about maximum acceptable staleness and minimum community footprint for third-party dependencies. It supports formalizing that policy once rather than re-litigating it per package.
• Risk framing for personal data. Address data is personal data under GDPR and similar regimes. An unmaintained package receiving user-supplied addresses is an unpatched input surface, and its outbound HTTP calls to provider adapters are unpatched too. That is a compliance argument, not a code-quality argument, and it belongs in the decision record.

When to Consider This Package

Adopt only in narrow, low-stakes circumstances:

• Legacy Symfony 2.x/3.x maintenance. You are keeping an existing application alive on an old Symfony line and this bundle is already installed there. Even then, pin and isolate it rather than extending it — note that Symfony 2.8 reached end of life in November 2018, so the surrounding framework is the larger risk.
• Reading it as a reference implementation. The source is more valuable as a design sketch for embeddable coordinates plus geocoder wiring than as a runtime dependency. Copy the pattern; don't take the dependency.
• Throwaway internal tooling where nothing is customer-facing, no PII beyond internal office addresses is involved, and nobody will be paged when it breaks.

Look elsewhere — or build — when any of the following is true:

• You are on Laravel. This is a Symfony bundle, not a Laravel package. There is no DI bundle system, Eloquent replaces Doctrine, and Symfony's compiler-pass-driven container has no Laravel equivalent. Using it means extracting the domain logic and rewriting every service definition and mapping, which costs more than writing the feature fresh.
• You are on modern Symfony (5/6/7). The bundle predates current bundle conventions and attribute-based mapping. Expect deprecation noise and friction for a very thin payoff.
• You need geocoding at any real volume. Provider coverage, retries, rate limiting, caching, and cost control are the actual work. Use a maintained geocoder library (for example geocoder-php with a PSR-18 client) and own that layer, or buy a geocoding API with an SLA.
• You need spatial queries at scale. Radius and polygon search belong in the database — PostGIS, MySQL spatial indexes, or a dedicated search service. A PHP bundle that stores coordinates does not solve query performance and will not be patched when your schema evolves.
• Compliance, security review, or support obligations apply. Zero dependents and five years without a release means no upstream security response and no one to escalate to. If you cannot accept that, you cannot adopt this.

Bottom line: do not adopt. The capability is small enough to build in-house in days; the package is framework-mismatched on Laravel; and it carries abandonment risk with no compensating benefit. Treat it as documentation, not a dependency.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source component for storing and geocoding location data on our records. The recommendation is to decline it and build the equivalent in-house. The component has effectively no user base, no release in five years, and no maintainer support, so it offers neither durability nor cost saving. The capability it provides is modest and replicating it is a short, well-understood piece of work. Building it ourselves keeps us on supported framework versions and keeps address data — which is personal data — inside code we control and can audit. The real investment in any location feature is the geocoding service and the spatial search, not this library; this decision does not change that budget.

To engineering: This is a Symfony 2-era bundle, not a Laravel package — adopting it means porting, not installing, and there is no plausible path to composer require it into our stack. It has been unmaintained since November 2020, with four stars and zero dependents, so there is no upstream to fix bugs or security issues for us; the steady state would be a permanent internal fork, which is the worst maintenance profile available. The useful output of the review is its shape, not its code: an embeddable lat/lng value object on the entity, geocoding pushed to a service layer behind an interface with a caching decorator, coordinates persisted separately from the display address, and any non-interactive geocoding queued with rate limiting and backoff. Build that against a maintained geocoder client, put radius and polygon search in the database (PostGIS or spatial indexes) rather than in PHP, and keep address fields behind our own normalization and retention rules. Sequencing: a half-day requirements workshop to pin down use cases and precision, then storage choice, then the value object and cast with unit tests, then the geocoder integration and caching, then queue and rate limiting. The entity work is small; the provider integration, caching, and cost controls are the items worth planning properly.