Formerrorsbundle Laravel Package

Product Decisions This Supports

• Form error presentation / UX consistency. This bundle addresses a specific, recurring UX gap: Symfony’s native $form->getErrors() returns only errors bound to the root form, not to individual fields or nested subforms, and getErrorsAsString() omits field labels. The package flattens the full error tree into an array and exposes it via a Twig extension, so a single template loop can render a complete, human-readable error summary (including labels) at the top of a form. That is a legitimate design decision: consolidated error summary vs. per-field inline errors.
• Build vs. buy for a small utility. The work being replaced is roughly a 30–60 line recursive form-error walker plus a Twig extension. This is a "buy" only when the cost of vetting (license, compatibility, maintenance risk) is lower than the cost of writing and owning those lines. Here, the honest answer is usually build — the package is a thin convenience wrapper, MIT-licensed, with no proprietary logic worth licensing.
• Roadmap signal for validation/error handling. If your product roadmap includes accessible error summaries (WCAG-style "there are N problems with this form" patterns), localization of validation messages, or API error envelopes mirroring form errors, this package is a useful reference implementation for the flattening shape (field label → messages), not a dependency to adopt.
• Framework-fit decision. Despite the "Laravel/PHP" framing, this is a Symfony 2 bundle (Ex3v\FormErrorsBundle), not a Laravel package. For a Laravel roadmap item, treat it as prior art only: Laravel already ships ValidationException, the $errors MessageBag, and the @error directive, which cover the single-level case. The only overlap is nested/array validation error flattening with human labels, which is a small custom helper in app/Support — not a Composer dependency.
• Risk/portfolio decision. With 11 stars, 0 dependents, and the author’s own disclaimer ("did not test on other versions… I don't guarantee this"), adoption is a maintenance-liability decision, not a capability decision.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony 2.3–2.4 era code and are not migrating soon; the author targets 2.3.13 explicitly.
• You need a quick, low-effort error summary with labels and have no appetite to write the recursive walker yourself.
• The surface area is internal/low-traffic (admin back office, internal tooling) where a pinned, unmaintained Composer dependency is acceptable.
• You can vendor/fork it and accept ownership — MIT license permits this, and given the size that is the realistic path.

Look elsewhere (or build in-house) when:

• You are on Laravel — no compatibility, no benefit; use the framework’s MessageBag/$errors and a small flattener for nested arrays.
• You are on Symfony 4/5/6/7 — FormErrorIterator, getErrors(true), and modern Twig form theming make this redundant and the bundle likely uninstallable.
• You have security, accessibility, or SLA obligations — an unmaintained package with a self-declared compatibility disclaimer fails most dependency-review gates.
• You need localized or API-shaped errors — the flattened array is convenient for HTML but not a contract you should build an API on.
• You want long-term ownership — the cost of forking, testing across your Symfony version, and maintaining a Twig extension exceeds writing the equivalent helper.

How to Pitch It (Stakeholders)

To executives (30 seconds): There is a tiny open-source helper that solves a narrow presentation problem — showing every validation error on a form, with field labels, in one list. It is MIT-licensed and free, but it is a Symfony 2-era bundle with a single-digit user base, no downstream dependents, and an author who explicitly disclaims support for other framework versions. Recommendation: do not add it as a dependency. The functionality it provides is small enough to implement in-house in under a day, and doing so removes a maintenance and audit liability. Its main value to us is as a design reference for how to flatten nested form errors into a labelled, accessible error summary.

To engineering: This is not a Laravel package — it’s Ex3v\FormErrorsBundle for Symfony 2.3. It does two things: a service that recursively exports all form errors (root + fields + subforms) to an array, and a Twig extension that renders them as a list with labels. That solves a real gap in old Symfony (getErrors() is root-only; getErrorsAsString() drops labels). On our stack, the equivalent is a ~50-line recursive flattener over Laravel’s MessageBag / nested validation errors, plus a Blade partial — testable, no supply-chain surface, and we own the label mapping and localization. If we later build an accessible "error summary" component, use this repo’s output shape as a starting spec: label => [messages], recursively, deduplicated at the root.

Bottom line for the decision log: Note as prior art; do not adopt. Revisit only if we inherit a Symfony 2.3 codebase that already depends on it.