Geolocation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for geo features. This package is best read as a design brief, not a dependency. Its value is the model it encodes: coordinates attached to any entity, addresses promoted to first-class entities rather than denormalized string columns, and distance computed in SQL via custom Doctrine functions. That is a coherent, still-defensible data model for store locators, delivery-radius checks, "near me" search, and user location profiles.
• Schema decisions you will otherwise re-litigate mid-sprint. Two questions this package answers early: (1) do we store lat/lng as decimals on the parent row, or in a separate locations table with history? (2) is an address reusable/shareable (many entities, one address) or owned? The bundle picks "address entity + attached coordinates," which is the right call if you expect multiple address types per user (billing, shipping, service) or want to dedupe on normalized address.
• Where to compute distance. The bundle's Doctrine DISTANCE/haversine functions are a useful reference for the cheap version of this: compute distance in the query, sort and filter in one round trip. That supports a scoping decision — "SQL-side haversine is good enough for v1 under ~tens of thousands of rows; a spatial index or PostGIS/MySQL 8 ST_Distance_Sphere is a later migration" — without paying for a spike.
• Use cases it legitimizes scoping for: proximity/dealer search, radius filtering on delivery or serviceability, customer address books, geo-tagged inventory or listings, and distance-based sorting in admin back office.
• What it does not support: any decision that assumes maintained code. Do not let its existence tilt a build-vs-buy call toward buy. There is no vendor, no CVE process, no PHP 8 path, and zero downstream dependents to reveal production hardening.

When to Consider This Package

Consider it only as a reference artifact — an hour of reading during a discovery spike, to borrow the entity model and the SQL distance-function approach. Nothing more.

Explicitly do not adopt it as a runtime dependency if any of the following is true — which is all of them:

• You are on Laravel. This is a Symfony2 bundle. It ships a bundle class, DI extension, and Doctrine bridge wired for Symfony's container. Laravel has no bundle concept; there is no service provider, no facade, no config publishing. "Integrating" it means rewriting the integration layer and most of the entity glue, which is the entire package.
• You need a supported PHP version. Last release January 2015 means PHP 5.x-era code, Symfony 2.x (EOL since 2018), and Doctrine 2.4-era APIs. Expect fatal errors on PHP 8.1+ and deprecation noise on 7.4.
• You need security response. The repository is archived. A CVE in its dependencies will never be patched here; you would be forking and owning it.
• You need evidence of production use. 12 stars, 0 dependents, archived — there is no signal that anyone runs this, no issue history to mine for failure modes, and no community to ask.
• You need geocoding or reverse geocoding. This bundle models coordinates; it does not resolve addresses to them. Use geocoder-php or a hosted provider (Mapbox, Google, Nominatim) for that.

Look elsewhere when you need to actually ship:

How to Pitch It (Stakeholders)

To executives — one line: this is a ten-year-old, archived library with no maintainers and no adopters; we are not going to build on it. We are going to take roughly a day of design inspiration from it and then build or buy something current.

The business case in plain terms: geo features (store locator, serviceability checks, distance sorting) are on the roadmap regardless. The question is only how we get them. This package would add schedule risk — it targets a framework generation we do not run, and any security issue in it is ours to fix forever. The cost of doing it properly is small: a modern library is a dependency line in composer.json, and the fallback is a one-to-two sprint internal build using the same data model this bundle describes.

To engineering — the honest framing: the transferable assets are the schema (coordinates attached to entities, addresses as entities) and the pattern of a SQL-side distance function. The transferable code is near zero: it is a Symfony2 bundle, and the Doctrine functions are on the order of a few dozen lines of SQL you would write yourself. Do not attempt to shim the bundle into Laravel — budget the rewrite instead, because the DI and entity glue is the package and it does not survive the port.

Risk register items to state plainly: archived repository; last release 2015-01-09; 12 stars; 0 dependents; no PHP 8 support; EOL framework dependency; no security patching path. A low confidence score (0.06) on package quality is consistent with all of the above — treat it as a do not adopt signal, and if we cite it anywhere, cite it as a design reference with a link, not as a dependency.

Recommended next step: spend one hour reading the entity model during discovery, write a two-page design note (tables, distance strategy, prefilter thresholds), and pick a maintained library or an internal implementation before the sprint starts.