Form Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle, not a Laravel package. It ships a PHP form abstraction over JSON Forms and exposes the result through an HTTP interface — meaning the server's real product is a JSON payload (JSON Schema + UI Schema + data) that a client-side renderer consumes. That distinction drives everything a TPM needs to decide:

• Not installable into Laravel as-is. There is no FormServiceProvider, no Laravel service provider, no Blade/Livewire integration, no FormRequest bridge. The bundle registers controllers, services and configuration through Symfony's DependencyInjection/HttpKernel lifecycle. Composer will resolve it, but nothing will boot in a Laravel kernel.
• The genuinely reusable asset is the contract, not the code. The schema/uischema/data envelope and the form-processing HTTP surface are framework-neutral. That is portable to Laravel; the Symfony wiring around it is not.
• Scope is narrower than "form builder." This is a server-side renderer/processor for declaratively defined forms. It will not give us drag-and-drop authoring, and it will not replace Blade form components for simple CRUD. Value concentrates in configurable, frequently changing, multi-step forms.

Integration feasibility. Three viable paths, ranked by realistic cost:

Technical risk.

• Adoption risk (high). 0 stars, 0 dependents. There is no third party to lean on: no Stack Overflow corpus, no community patches, no forked escape hatch. Every issue becomes a vendor conversation.
• Governance risk (medium-high). Single-vendor (Sitepark) stewardship with an atoolo ecosystem behind it. The bundle is likely fit-for-purpose inside their CMS product; our use case is a secondary consumer. Roadmap influence ≈ 0.
• Correctness/quality signal (medium). 1.1.0 shipped with a dependency bump specifically to clear a security audit, plus a CI fix for a missing test directory — that is a signal the test surface is thin and not a gating concern for releases. Plan on writing our own conformance tests against the schema output rather than trusting the suite.
• Metadata risk (low but real). The listed "last release 2026-10-01" is a future-dated tag. Verify what that actually is (likely a scheduled/mistagged release) before quoting version numbers to stakeholders.
• Learning-curve risk (medium). JSON Forms' three-document model (schema / uischema / data) plus JSON Schema semantics ($ref, oneOf, conditional if/then) is a genuine skill, not a day-one competency. Budget for it.

Key questions to resolve before committing.

1. Which forms actually need runtime configurability? If the answer is fewer than ~10 forms, this is over-engineering and Blade/Livewire wins on total cost of ownership.
2. Who owns the frontend renderer? JSON Forms needs a React/Vue/Angular renderer. If our frontend is Blade + Alpine, this bundle delivers nothing usable and Option B collapses too.
3. Are we willing to operate two PHP runtimes (Option A), or is a single-runtime estate a hard constraint?
4. What is the exit plan if the vendor stops publishing? (Acceptable answer: we only depend on the JSON contract, so exit = reimplement, not migrate data.)
5. Does the evaluation spike get funded as a 2-week timebox with a kill criterion, and what is that criterion?

Integration Approach

Stack fit. Fit is conditional and asymmetric:

• Good fit — Laravel API + a JS SPA (React/Vue) where the frontend already owns rendering, and form definitions change more often than deploys.
• Poor fit — server-rendered Blade/Livewire apps, or teams without a JS component layer. There is no Blade rendering path in this package, and none is planned.
• Neutral — anything using laravel/framework v10/v11 (PHP 8.1–8.3 aligns; Symfony components ship as Laravel transitive deps, but that is not the same as bundle compatibility — do not let anyone conflate the two).

Migration path. Incremental, one form at a time, never a big-bang:

1. Spike (timeboxed). Stand up the bundle standalone; author one real schema; confirm the schema/uischema/data envelope does what our form needs (including a conditional field and a server-side validation error). Kill criterion documented up front.
2. Choose the seam. Default to Option B (Laravel emits the same contract) unless the frontend is already JS-first, in which case Option A (headless service) is cheaper because we inherit the vendor's processing logic.
3. First production form. Pick one admin/internal form — low blast radius, high change frequency. Never a customer-facing or payment-adjacent form first.
4. Backfill. Only after two consecutive forms are cheaper to build with the new path than the old one. That measurement is the real go/no-go for wider adoption.

Compatibility. PHP 8.1–8.3 is our lane. Note explicitly in the ADR:

• The bundle's own versioning (1.1.0 stable, past the 1.0.0-beta series) is healthier than the repo's public signals suggest — but stability ≠ support.
• Symfony major-version coupling is a standing cost: a future Laravel upgrade that bumps Symfony components could strand an Option A/B deployment. Pin and test.
• Frontend compatibility is the sharper constraint: JSON Forms renderers are versioned separately from the PHP side, and the schema dialect matters. Lock the JSON Forms renderer version in the same PR that introduces the backend contract.

Sequencing.

Operational Impact

Maintenance. Two cost centres, only one of which is visible at kickoff:

• Code — schema definitions become a managed asset: versioned, reviewed, linted in CI. Treat a broken schema as a production incident, because it is one: the form stops rendering for users.
• Dependency — someone must own Symfony-component pinning and JSON Forms renderer upgrades. If no one is named, this silently decays. I would want that owner named in the ADR.
• Divergence risk — if we run Option B (reimplementation), our contract drifts from the vendor's. Acceptable if we deliberately fork the contract and stop tracking upstream. Half-tracking is the worst outcome.

Support. On-call implications get understated here:

• Error traces span frameworks in Option A/C, so first-response triage time increases. Budget for runbook work, not just code.
• No community to search. Every non-trivial bug is a vendor ticket with unknown SLA — a dependency our incident process does not currently model.
• Skill concentration: expect 1–2 people to be genuinely productive. That is a bus-factor of one. Mitigate with written integration docs from week one, not after launch.

Scaling.

• Option A adds a network hop per schema fetch and per submission. Mitigate by caching schema responses aggressively (they are near-immutable per form version) and keeping submission calls synchronous only where validation must be authoritative.
• Form submission volume, not form count, is the scaling axis. If forms are low-traffic admin surfaces (the likely case), scaling is a non-issue; the second runtime's fixed cost dominates. Be honest that we are buying capability, not throughput.
• Storage — submission persistence is ours to own regardless of option; the bundle is not a submissions datastore. Model that as a first-class table set with retention policy, not an afterthought.

Failure modes.

Ramp-up. Realistic learning curve: 1 week to author a non-trivial JSON Forms schema competently, 2–3 weeks to be productive across schema + renderer + server validation together, longer if the team has no JSON Schema background. Add frontend capacity if the renderer library is new to that team — this is a full-stack adoption disguised as a PHP package.

TPM recommendation. Score it honestly: the pattern is high-value, the package is a low-confidence dependency. Fund a 2-week spike with an explicit kill criterion, default to the contract-reimplementation path unless a second runtime is already acceptable operationally, and commit to adoption only after cost-per-form demonstrably beats the Blade/Livewire baseline. Do not present this to stakeholders as a Laravel package — it is a Symfony service with a portable JSON contract, and scoping it that way is what keeps the estimate honest.