Form Spatial Laravel Package

Technical Evaluation

Headline: This is not a Laravel package. It is a Symfony2 bundle (FormSpatialBundle) that integrates spatial/geometry form types with Symfony's Form component and (typically) Doctrine spatial column types. As a dependency for a Laravel codebase, direct architecture fit is effectively zero, and the surrounding signals — archived, last release 2018-04-19, 7 stars, 0 dependents, GPL-2.0 — make adoption a non-starter. The assessment below treats it as a design reference and a requirements source, not a dependency.

Architecture fit

• Bundles are Symfony-specific artifacts: they register services into Symfony's DI container, hook the Form component's type/extension system, and assume Symfony's event dispatcher and templating. Laravel exposes none of these surfaces natively.
• Any real use requires either (a) pulling Symfony Form into a Laravel app as a parallel form/validation stack, or (b) forking and porting. Both are architectural regressions for a product team.
• The concept — a map-driven geometry input with WKT/GeoJSON serialization and server-side validation — is stack-agnostic and worth extracting.
• The underlying spatial dependency chain (Doctrine spatial abstractions) is also a mismatch with Eloquent.

Integration feasibility

• No-drop-in path. Modern Laravel runs PHP 8.2–8.4; a Symfony2-era bundle almost certainly constrains to PHP 5.6/7.x and Symfony 2.x/3.x components. Expect an immediate Composer resolution conflict.
• Bridge path (not recommended). Adding symfony/form alongside Laravel's validator and Blade creates two validation models, two rendering models, and a translation layer. High carrying cost for one field type.
• Port path (recommended if anything is reused). The genuinely useful surface is small: form type definitions, a JS map widget, and geometry serialization. This is a days-to-weeks reimplementation in Laravel, not a migration.
• Reimplement path (strongly recommended). Leaflet/MapLibre + an Livewire or Alpine component + a GeoJSON/WKT hidden input + a FormRequest rule + an Eloquent cast for the geometry column.

Technical risk

• Lifecycle risk: critical. Archived repository, no maintainer, no security response channel. Any CVE in the embedded map JS or PHP glue becomes permanently ours.
• Version risk: critical. Symfony 2.x is long EOL (2.8 in Nov 2018); PHP support ceiling is well below current runtime.
• License risk: high. GPL-2.0 is strong copyleft. For a proprietary Laravel SaaS, linking GPL code into the application creates a strong argument that the combined work must be GPL. A fork inherits the obligation. This alone typically fails legal review.
• Validation risk: high. 7 stars and 0 dependents means no production evidence, no issue history worth trusting, and no ecosystem pressure to keep it correct.
• Scope risk: low. The functional gap it addresses is real and small; it does not justify disproportionate risk.

Key questions

1. What is the actual user need — capture a point, capture arbitrary geometry (lines/polygons), or merely display a stored geometry? Point-only is a fraction of the effort.
2. What is the spatial backend — PostGIS, MySQL spatial, or plain lat/lng columns? This drives validation and persistence far more than any form package.
3. Is write access to geometry required in the UI, or is read/render sufficient for the current milestone?
4. Has legal reviewed GPL-2.0 exposure, and is any code reuse (even "inspiration") contemplated?
5. Is there a maintained alternative already vetted (map component library, geospatial Laravel packages), or is native build the shorter path?
6. What is the composite score threshold for this team's intake process? At 0.0775, this should fail intake by policy before engineering time is spent.

Integration Approach

Stack fit

• Poor by construction. The package assumes Symfony full-stack (DI container, Form types, Twig rendering). Laravel's equivalents are Blade/Inertia/Livewire, FormRequest validation, and Eloquent casts.
• The only transferable assets are the shape of the form type (map widget bound to a geometry value) and the serialization conventions (GeoJSON/WKT).
• The JS rendering layer (Leaflet-era) is independently replaceable and should be chosen fresh against current browser and CSP requirements.

Migration path

• Do not install. Treat the repository as a specification artifact: read the form type and widget to enumerate required behaviors, then close the tab.
• Decompose into four deliverables: (1) a geometry input control with a map picker; (2) client-side serialization to GeoJSON with a WKT fallback; (3) server-side validation rules (coordinate bounds, geometry type, SRID); (4) persistence via a spatial column and an Eloquent cast.
• Estimated effort: 1–2 days for point capture with Leaflet and a hidden GeoJSON input; 1–2 sprints for a robust multi-geometry editor with validation, SRID handling, and tests.
• If a fork is genuinely unavoidable (it is not), isolate it behind an internal interface, vendor it, and assume full ownership including license obligations — budget ongoing maintenance headcount, not a one-time cost.

Compatibility

• Expect hard blockers on PHP 8.x, Symfony 4+/Laravel 9+, and Composer 2 dependency resolution.
• No Laravel service provider, facade, config publishing, or migration support exists; every Laravel-side integration point would be net-new code.
• No compatibility with Laravel's validation error bag or old-input repopulation without custom glue.

Sequencing

1. Confirm the requirement and the spatial DB capability (PostGIS vs MySQL spatial vs lat/lng) — this decision dwarfs the package question.
2. Run intake against the score threshold and license policy; document the rejection so it is not re-litigated.
3. Spike the native path: Leaflet + GeoJSON hidden input + FormRequest rule + cast, timeboxed to 2 days for point-only.
4. If multi-geometry is required, scope it explicitly and sequence validation/SRID work before UI polish.
5. Only if the spike fails on a concrete technical gap, evaluate maintained third-party alternatives — not this repository.
6. Ship with tests around serialization round-trips and malformed geometry rejection.

Operational Impact

Maintenance

• Upstream maintenance is zero and permanent: archived means no bug fixes, no dependency bumps, no security patches, and no release process.
• Any fork becomes a forever-owned artifact, including the GPL-2.0 obligation, which propagates to the derived work.
• The native alternative's maintenance surface is a small internal component with a handful of JS dependencies that the team already tracks via its normal dependency policy — strictly smaller than owning a dead Symfony bundle.

Support

• No maintainer, no active issue triage, no community. With 7 stars and 0 dependents, there is no peer support network and no evidence any team runs this in production.
• Internal support burden falls entirely on the adopting team, with no upstream escalation path for defects.

Scaling

• The package itself is not a scaling concern — it is a form widget plus a payload serializer. Geometry editing is client-side work.
• The real scaling levers are independent of this package: geometry payload size over the wire, SRID/index strategy, and spatial query performance on the database. These should be designed directly rather than inherited from a 2018 abstraction.

Failure modes

• Composer resolution failure on modern PHP/Composer 2 — surfaces immediately, low cost.
• Dual form-stack conflicts if bridged (validation divergence, escaping differences, repopulation bugs) — surfaces late, high cost.
• Unpatched vulnerabilities in embedded JS map dependencies — surfaces silently, potentially as a security incident.
• License contamination of a proprietary codebase — surfaces at diligence, acquisition, or audit, with remediation cost far exceeding any build savings.
• Silent divergence after forking, with no upstream signal to detect regressions.

Ramp-up

• Evaluation ramp-up is trivial: a few hours to read the form type and confirm the Symfony2 scope.
• Build ramp-up for the native replacement is moderate for one engineer familiar with the frontend stack, and the deliverable is small and well-bounded.
• The unfavorable trade is stark: low one-time build cost versus permanent ownership of an archived, copyleft, unmaintained dependency. The composite score of 0.0775 is consistent with this conclusion — recommendation: reject as a dependency, extract the requirements, build native.