Xrow Gis Bundle Laravel Package

Technical Evaluation

• Framing check first. This is not a Laravel package. It's a Symfony bundle for eZ Publish 5 (eZ5), the 2012–2015 generation of eZ Systems' CMS. The "Laravel/PHP" tag is a catalog artifact, not a description of the integration surface. An assessment that assumes composer require into a Laravel app is mis-scoped from the start.
• Architecture fit: poor. eZ5 datatypes plug into eZ Publish's content model — eZDataType subclasses, eZContentClassAttribute, eZPersistentObject persistence, and the legacy attribute storage engine. None of that maps to Eloquent, migrations, or Laravel's casts. The description ("Fixes custom xrow datatypes XrowGis for eZ5") also implies this is a patch/companion to a separate parent xrow implementation, not a standalone library.
• Integration feasibility: near zero for a Laravel stack; non-trivial even on eZ5, where you'd need a matching eZ5 kernel and the parent custom datatype the bundle "fixes."
• Technical risk: very high. Zero stars, zero dependents, a single release in Aug 2016, and no evidence of tests, CI, or a security disclosure process. The code predates PHP 7.1; transitive dependencies almost certainly no longer resolve. A 0.03 score is consistent with an abandoned internal artifact that leaked to Packagist.
• Key questions for the requester:
  1. What is the actual requirement — storing/validating geo coordinates on content, or full proximity/spatial query?
  2. Are we running eZ Publish 5 or Ibexa anywhere today?
  3. Is there a parent xrow package we'd also need to source and pin?
  4. Who owns the upstream fix, and is this a fork of something lost?
  5. Given nine years of drift, is the "fix" already solved by a maintained library?

Recommendation: do not adopt. Use at most as a reference implementation for what the legacy datatype did.

Integration Approach

• Stack fit: none with Laravel. For geo attributes on content, the native path is a spatial column (PostGIS / MySQL 8 geometry, or decimal lat/lng) on the target model, exposed via a cast or value object, with proximity handled by grimzy/laravel-mysql-spatial or direct ST_* queries. That is a 1–2 day build, fully maintained.
• Migration path (if eZ5 data exists today): extract the datatype's semantics — coordinate format, precision, validation rules, null handling, and the columns it writes — then reimplement those rules as a Laravel cast plus migration. Port the contract, not the code.
• Compatibility: the bundle targets the Symfony 2.x-era eZ5 kernel and the legacy storage engine. It will not install cleanly against modern Symfony (5/6/7) or PHP 8.x, and Composer will likely fail on transitive constraints. Treat any successful install as a surprise, not a plan.
• Sequencing if pursued anyway (eZ5 only): 1) confirm the parent xrow datatype and version; 2) fork and pin the bundle; 3) stand up the eZ5 dev environment; 4) verify the specific bug it fixes is your bug; 5) regression-test the datatype across create/edit/publish; 6) freeze. Budget a spike first — this is a 3–5 day investigation with a real chance of dead-ending.
• Sequencing for the native replacement: model the geo field → choose storage (decimal vs geometry) → cast and validation → backfill/migrate → feature-flag → cutover → retire the eZ5 path.

Operational Impact

• Maintenance: effectively nil upstream. Last release Aug 2016, no maintainer activity, zero dependents — meaning no one is exercising the code, so regressions would go unnoticed. Adoption is a fork-and-own decision; budget for it being permanently yours.
• Support: community-only, and there is no community. No issue triage, no advisories, no upgrade path. Supplier risk is high and unmitigable except by owning the code outright.
• Scaling: the package is thin — a datatype storing a scalar geo value per content attribute. Scaling is a database concern (row-per-attribute, join-heavy content queries), not something this bundle addresses or worsens. Critically, it does not deliver proximity/radius search; if that's the requirement you need an index (PostGIS/GiST or a search engine) regardless.
• Failure modes: Composer resolution drift against abandoned transitive deps; PHP 8 / modern Symfony incompatibility; silent coordinate or validation bugs with no tests to catch them; an orphaned eZ5 runtime if the CMS is retired mid-project; and the classic — the "fix" targets a parent-package version you don't have.
• Ramp-up: low line count, high context cost. eZ Publish 5 datatype internals are niche and increasingly unhireable; the knowledge is more expensive than the code. A Laravel-native replacement onboards faster than porting this, which is the strongest argument against adoption.
• Bottom line: score 0.03, zero dependents, a nine-year-old release, and a stack we don't run — reject as a dependency. Log it only as a reference for legacy GIS datatype behavior, and fund the 1–2 day modern equivalent instead.