Form Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy / adopt-vs-replace on forms: The package's stated value — declarative, RIA-style form widgets "without writing a single line of javascript" — maps directly onto a recurring PM decision: do we buy form ergonomics or build them on Livewire, Filament Forms, Inertia, or Blade components? This package informs that decision as a cautionary reference, not a candidate. Treat it as evidence that the capability is valuable and that the ecosystem already solves it natively.
• Framework-fit gating for the roadmap: Despite being filed here as a Laravel/PHP package, the repository is a Symfony bundle (NeutronFormBundle, *-bundle convention, symfony/form dependency, Twig form themes, config/bundles.php). For a Laravel product the integration cost is a rewrite, not a config change. This supports a standing decision rule: framework-mismatched dependencies do not enter the backlog, regardless of how attractive the pitch reads.
• Roadmap prioritization and risk budgeting: 0 stars, 0 dependents, score 0, no vendor or maintainer signal. Adopting it means owning 100% of maintenance, security review, and PHP/Symfony upgrade work indefinitely. That is a roadmap liability, not a feature investment — it should be scored as unbounded operational cost against a bounded UI benefit.
• Scope decisions on JS-avoidance / strict-CSP requirements: If a product requirement is genuinely "no client-side JavaScript" (strict CSP, locked-down enterprise or kiosk environments, accessibility-first admin tooling), the underlying need is real. The correct response is a scoped spike in the team's own stack — Livewire for reactivity, Filament for admin scaffolding, plain Blade + Form Requests for static forms — not this bundle.
• Prototype / spike authorization: Justifiable only as a 2–3 day timeboxed artifact to extract a behavioral spec (field types, conditional visibility rules, validation semantics, AJAX contract), then reimplement natively and archive the dependency. Never a production dependency.
• Vendor and security posture for input-boundary code: Form packages sit directly on untrusted input. Zero dependents means zero external eyes on injection, mass-assignment, and CSRF handling, and no advisory channel. This reinforces a governance rule: no unmaintained packages on the input boundary, full stop.

When to Consider This Package

• Only if the codebase is a Symfony application, the form scope is small and internal (admin tools, back-office), the team already holds Symfony Form expertise, and there is an explicit, funded fork-and-own commitment with an assigned maintainer.
• Only as a time-boxed technical spike (2–3 days, hard exit criteria) to validate whether a specific no-JS RIA form pattern is viable, with the output being a written behavioral spec — not a merged dependency.
• Only if the organization accepts, in writing: no vendor support, no SLA, no issue triage, unknown CVE exposure, unverified PHP 8.2+ and modern Symfony compatibility, and a bus factor of effectively one.
• Look elsewhere for any Laravel product. There is no service provider, facade, config publishing, or Blade layer. Symfony Extension and CompilerPass classes are inert in Laravel; bridging means bespoke glue the team owns forever, for a package with no upstream maintenance.
• Look elsewhere for customer-facing forms, complex multi-step validation, payment or PII entry, accessibility commitments, localization at scale, or anything requiring predictable upgrade paths.
• Look elsewhere by default toward Livewire, Filament Forms, Inertia, or first-party Blade + Form Requests — actively maintained, documented, widely adopted, and hireable. If a spike confirms the capability is needed, that is the sanctioned path.
• Stop the evaluation immediately if composer.json shows a hard symfony/framework-bundle constraint or PHP 5.x/7.x-only ranges. That is a terminal finding, not a negotiation point.

How to Pitch It (Stakeholders)

• Executive summary: Attractive pitch, unproven and structurally mismatched package. It is a Symfony bundle with no measurable adoption — 0 stars, 0 dependents, no maintainer signal — and it does not run in Laravel without a rewrite. Do not adopt it as a strategic or production dependency. The capability it promises is real and already served by maintained tools we can hire for.
• Engineering summary: firano/form-bundle offers reusable Symfony form types and Twig themes for rich widgets with minimal handwritten JavaScript. In Laravel, the realistic path is not integration but extraction: read the repo for its behavioral spec, then reimplement on Livewire or Filament Forms. That path costs days; a genuine Symfony↔Laravel bridge costs multi-week and leaves us maintaining three layers indefinitely.
• The ask: Approve a short, bounded evaluation (2–3 days) to formally close the question and document the outcome, so the decision is recorded rather than relitigated. No production spend, no procurement, no legal review needed beyond confirming MIT.
• The risk if we adopt anyway: Silent abandonment after a PHP upgrade; an unpatched input-handling flaw surfacing as an incident rather than a CVE; an upgrade deadlock that forces an emergency rewrite under deadline; and tribal knowledge concentrated in one engineer who eventually leaves.
• Recommendation: Do not adopt. Record the Symfony/Laravel incompatibility as the formal rationale, direct the underlying form-ergonomics requirement to Livewire or Filament Forms, and keep this repository as reference material only.