Form Extra Bundle Laravel Package

Product Decisions This Supports

• Form UX scope decisions. This bundle is a catalog of "form polish" features that product teams routinely debate: enhanced select widgets (Chosen-style searchable dropdowns), entity-backed autocomplete fields, rich-text/WYSIWYG editors, and CAPTCHA on public submissions. Use it as a checklist when scoping an admin or onboarding form backlog — it answers "what does good-enough form UX look like?" faster than writing a spec from scratch.
• Build vs. buy vs. borrow. The decision this package most credibly supports is borrow: read the source, copy the pattern, don't add the dependency. It is a reference implementation, not a vendor.
• Framework fit (important correction). The brief frames this as a "Laravel/PHP package." It is a Symfony2 bundle — PHP, but not Laravel, and not portable to Laravel without a rewrite of the form-type layer against Laravel's validation/binding model. Any roadmap item that assumes drop-in Laravel reuse is invalid; treat this as Symfony-only prior art.
• Legacy platform triage. If the product still runs Symfony 2.x, this bundle is a short-term bridge candidate for form enhancements that would otherwise consume a sprint. That's a maintenance-budget decision, not a product-differentiation one.
• Roadmap signal, not roadmap item. With 99 stars, 0 dependents, and a last release of 2014-06-19, there is no ecosystem validation. The useful signal is the problem space (form ergonomics, autocomplete, WYSIWYG), not this artifact. Modern equivalents — Symfony UX/Twig Components, Stimulus-based controllers, maintained editor and select libraries — are where roadmap investment belongs.
• Risk register input. CAPTCHA and rich-text integrations age badly (third-party JS APIs sunset, XSS surface grows). This package is a concrete example to cite when arguing for "no unmaintained front-end integrations in customer-facing forms."

When to Consider This Package

Consider it only when all of the following hold:

• The application is on Symfony 2.x (roughly 2.3–2.8) and there is no funded path to Symfony 4+/6+/7 in the current planning horizon.
• The need is internal or low-traffic — back-office admin screens, internal tooling — not a public, security-sensitive, or accessibility-audited surface.
• The team is already comfortable with the era's jQuery stack (Chosen, jQuery UI autocomplete, CKEditor/TinyMCE) and accepts those as given.
• You are prepared to vendor/fork and pin the code: verify the license, copy it into the repo, add your own tests, and own it forever. Treat it as source code you inherited, not a package you depend on.
• The work is a time-boxed bridge (days, not quarters) with an explicit exit criterion.

Look elsewhere when:

• You are on Laravel. Different framework, different form/validation model. Nothing here transfers.
• You are on Symfony 4+ or PHP 8. Released June 2014, unmaintained for over a decade; expect incompatibilities with modern form types, autoloading, and PHP type semantics. Do not attempt to install it.
• You need maintained dependencies. 0 dependents and no releases since 2014 mean no security response, no bug fixes, and no community answer to "why did this break?" Your SCA tooling will flag it, and rightly so.
• Customer-facing forms are involved. Legacy CAPTCHA integrations in particular may point at retired third-party endpoints — a silent conversion killer — and rich-text editors are an XSS surface you cannot patch.
• Accessibility or design-system consistency is a requirement. These widgets predate modern a11y expectations for comboboxes and autocomplete; retrofitting ARIA is usually more work than adopting a current component.
• You need a decision you can defend in a review. "Adopted an eleven-year-old bundle with zero downstream users" is a hard sentence to say out loud.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, abandoned Symfony 2 add-on for form widgets — searchable dropdowns, autocomplete, rich-text editors, CAPTCHA. It is not a Laravel package and cannot be dropped into a Laravel codebase. It has 99 stars, no downstream projects, and no release since June 2014. My recommendation is not to adopt it as a dependency. The value is as a reference: it shows the exact set of form enhancements users expect, which lets us scope our own form work quickly and pick maintained, modern components instead. Cost of the "borrow" route: a day or two of reading. Cost of the "adopt" route: an unpatched dependency we own indefinitely.

For engineering leads: Treat the repo as documentation. Pull the ideas — an entity-backed autocomplete form type, a WYSIWYG type, a select-enhancement type — and reimplement against Symfony UX / current libraries, or point at maintained alternatives. If a Symfony 2.x system genuinely needs a bridge this quarter, fork it into the repo, pin it, add tests, document the owner and a removal date, and log it as technical debt with a named exit criterion. Do not add it to composer.json from Packagist. Please also confirm the license before any code is copied.

For the product team: Nothing here changes the customer experience on its own. It changes how confidently we can say "these four form capabilities are table stakes, let's schedule them properly" instead of rediscovering them per feature. The opportunity is in the form-UX gap, not in this bundle.

Bottom line: Reference, not dependency. Score 2.49 with an opportunity signal of 5.06 reads exactly that way — a real problem area, served by an artifact too old to build on.