Product Decisions This Supports
- Build vs. buy for geo features. This package is a signal, not a solution: it confirms that "store coordinates on an entity, render pins on a map" is a commodity pattern, not a differentiated capability worth licensing. The decision it supports is build it in-house in days, do not spend roadmap time evaluating geo vendors or bundles.
- Feature scoping: what's in and out of a "store locator" / "map view" epic. The package covers exactly two layers — persistence (ORM/ODM annotations for address + lat/lng) and presentation (a JS map widget). It does not cover geocoding, address normalization, radius/distance search, clustering, routing, or tile hosting. That boundary is a useful scope line for an epic: storage + render is roughly 20% of a real geo feature.
- Roadmap risk flag. Last release April 2017, zero stars, zero dependents. Any roadmap item that assumes "we can just drop in a bundle" should be re-estimated as greenfield.
- Use-case triage. Applicable shape: property/listing detail maps, single-pin "find us" pages, event venue maps. Not applicable: multi-tenant geo search, delivery-zone polygons, real-time tracking — all of which need spatial indexing and query support this package never had.
- Architecture bet: persistence-agnostic geo attributes. The one genuinely interesting design idea here is decoupling geo metadata from a specific Doctrine driver (ORM vs. ODM). That is a real decision if you have a mixed MySQL/Mongo estate — but it is a 1-day refactor to replicate, not a reason to adopt.
- Dependency hygiene decision. Zero dependents is the strongest datapoint in this assessment: it means no one has validated it in production, so there is no indirect evidence to borrow. Treat as "reject" by default and require an explicit override to revisit.
When to Consider This Package
Consider only if all of the following are true:
- You are maintaining an existing Symfony 2.x/3.x application already on the
VichGeographicalBundle lineage, and this is the least-churn fork for a fix.
- The feature is internal, low-traffic, non-revenue-critical (admin back-office map, internal asset map).
- You need only entity-level address/coordinate storage plus a map render — no search, no geocoding pipeline.
- You are prepared to vendor the code, fork it, and own it — assume no upstream maintenance, no security patches, no PHP 8.x compatibility guarantee.
Look elsewhere (the default) if any of the following are true:
- Any new build. A 2017 last-release artifact predates PHP 7.2, modern Symfony, and PSR-compliant Doctrine attribute mapping. Compatibility work will exceed the cost of writing the feature.
- This is a Laravel codebase. Despite the "PHP package" framing, this is a Symfony bundle with a DI extension and bundle class — it does not drop into Laravel. Porting it is a rewrite.
- You need anything beyond rendering: geocoding/address normalization, distance and radius queries, bounding-box search, clustering, multi-pin performance. Reach for PostGIS or MySQL spatial indexes for query, Geocoder PHP for normalization, and Mapbox GL / Leaflet / Symfony UX Map for rendering.
- You need a support contract, CVE response, or a maintained upstream. There is none, and zero dependents means no community will emerge to provide one.
- You are on PHP 8+ or current framework versions — verify autoloading and annotation/attribute mapping before spending any spike time.
Practical test before adoption: one-day spike. Install in a scratch app, map a single entity, render a map. If it fails to install or needs more than a few lines of patching, stop — the build path is cheaper.
How to Pitch It (Stakeholders)
To executives (30 seconds): We evaluated this library and recommend not adopting it. It was last released in 2017, has zero stars and zero projects depending on it, and is unmaintained — meaning no security patches and no one to call if it breaks. The functionality it provides is small and standard: storing an address and coordinates on a record, and drawing a map. We can build that ourselves in roughly three to five developer days and own it outright. Adopting the library would trade a few days of work for permanent maintenance and security exposure on a customer-facing surface. Net: reject as a dependency, keep as a reference design.
To engineering leads: Don't plan around it. It's a Symfony bundle, not framework-agnostic PHP, so it doesn't fit anything but legacy Symfony 2/3. The two ideas worth scavenging are (a) geo fields as a reusable, persistence-agnostic entity concern, and (b) a declarative map widget driven by entity metadata. Both are a day's work to reimplement with current tooling. Recommended stack: spatial columns and indexes in the database for queries, a geocoding service for address→coordinate, and a maintained map library for rendering. If anyone is already running the older VichGeographicalBundle, that's the one case worth a short migration audit — and the output of that audit should be a removal plan, not a fork.
To the product team: Assume geo display is a small, owned feature, not a platform capability. Scope map work as "store coordinates + render pins" first; treat search-by-distance, clustering, and address autocomplete as separate, larger epics with their own infrastructure needs. Budget ~3–5 dev days for the base feature and do not schedule it against a third-party upgrade path.