Form Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on commodity form widgets. The package is a grab-bag of eight form field types (GD captcha, TinyMCE, ReCAPTCHA, jQuery date/autocomplete/slider/file/image). None of these are differentiators; this package is evidence that the whole category is commodity plumbing, so product time should go into what the form does, not how the widget is rendered.
• Scoping forms-heavy admin/CRUD features. If a roadmap item is "let ops upload images, pick dates, and edit rich text in the back office," this is a rough inventory of the widgets you'll need — useful as a checklist even if you never install it.
• Dependency-vetting and legacy archaeology. For an existing Symfony 3.x/4.x app inherited by the team, this is the kind of package you'll find in composer.json. The assessment output is a decision: keep, fork, or replace.
• Framework fit check (important). Despite the "Laravel/PHP package" framing, this is a Symfony bundle (SHFormBundle, folliked/form-bundle). For a Laravel codebase the answer is effectively "no" — it would require porting, which removes any time-saving rationale.
• Reference implementation. MIT-licensed, so the code can be read and lifted (e.g., how to wrap a jQuery plugin as a reusable form type) without taking the dependency.

Net PM read: this does not support a roadmap or investment decision beyond "widgets are solved; buy/borrow, don't build." It is not a candidate for a production dependency.

When to Consider This Package

Consider it only if all of the following hold:

• The stack is Symfony 3.x/4.x, not Laravel and not Symfony 5+.
• The front end is already jQuery-era server-rendered Twig — no Livewire/Inertia/Stimulus/Turbo in play.
• The surface is an internal admin tool with a small, trusted user base.
• You are willing to fork and own it: 0 stars, 0 dependents, last release 2020-06-04, no visible maintainer activity. Assume zero upstream support and zero security patching.
• You need exactly one or two of the widgets and are happy to delete the rest.

Look elsewhere — or build in-house — when:

• Framework mismatch: any Laravel project; any Symfony 5/6/7 project. The form-type APIs and jQuery assumptions won't line up.
• Security-sensitive fields: hand-rolled GD captchas and unmaintained ReCAPTCHA integrations are a liability (accessibility failures, bot-bypass, stale API versions). Use a maintained provider SDK.
• Accessibility, i18n, or design-system requirements: these widgets ship their own markup, which will fight a component library.
• Maintained alternatives exist for every single field: TinyMCE/Trifinity or CKEditor bundles, EWZRecaptchaBundle / gregwar/captcha (or a hosted captcha), Symfony UX / Stimulus controllers for datepickers, autocomplete, sliders, and file/image upload with validation.
• Compliance or long-lived product: an unmaintained dependency with zero adoption is a procurement and audit objection you will spend more time defending than replacing.

How to Pitch It (Stakeholders)

To executives: Recommend do not adopt. It's a 2020-era Symfony bundle with no stars, no downstream users, and no releases in ~5 years. The functionality — captcha, rich text, date pickers, file/image fields — is commodity and available from maintained libraries or roughly a day or two of in-house work. Adopting it converts a small build cost into an indefinite maintenance and security-ownership cost, for zero product differentiation.

To engineering: Treat it as a reference, not a dependency. It's a thin, MIT-licensed wrapper that turns jQuery plugins into Symfony form types; skim it if you need that pattern, then implement against maintained packages (Symfony UX/Stimulus, gregwar/captcha or a hosted captcha, your editor bundle of choice). If a legacy app already depends on it, quarantine it: pin the version, fork it into our namespace, audit the captcha and file-upload paths, and schedule replacement.

Bottom line: low strategic value, low quality signal, high ownership cost. Reject for new work; contain if inherited.