Form Error Log Bundle Laravel Package

Product Decisions This Supports

• Prioritizing form-friction work with evidence instead of opinion. The core capability — capturing which fields fail validation, how often, and with what messages — turns "users say checkout is confusing" into a ranked list of fields by failure rate. That directly informs whether the next sprint goes to copy changes, input masking, or a redesigned step.
• Funnel drop-off analysis at the validation boundary. Most analytics stacks capture page views and successful submissions but not the silent failures in between. Form-error telemetry closes that gap and lets you quantify how much revenue or signup volume is lost to specific validation rules.
• Roadmap sequencing for onboarding, checkout, and KYC flows. If 40% of failures cluster on one field, that field outranks whatever was queued next. This is a cheap input to quarterly planning.
• Build-vs-buy framing. The package is a reference implementation of a pattern, not a dependency to adopt. The decision it actually supports is "do we invest half a day of engineering to instrument our forms ourselves?" — and the answer is usually yes, regardless of what this bundle does.
• Identifying over-strict validation as a product problem, not an engineering one. Error logs reveal rules the business insisted on that are now costing conversions. That's a conversation with legal/compliance and product, and having the numbers makes it a short conversation.

When to Consider This Package

Adopt it only if all of the following hold:

• You are running a Symfony application (this is a Symfony bundle, not a Laravel package — there is no Laravel integration, no service provider, no facade, and it will not install meaningfully into a Laravel project).
• You are on a legacy Symfony 3.x-era codebase where the Form component's event system matches what this bundle hooks into, and upgrading the framework is off the table.
• You accept that the code is unmaintained and archived — last release November 2017, zero stars, zero dependents. No security patches, no PHP 8 compatibility, no answers to issues.
• The logging destination it ships with already matches your stack, so you are not writing a custom handler anyway.

Look elsewhere — or build — in every other case. Specifically:

• For Laravel: build it yourself. A middleware plus a listener on Illuminate\Validation\ValidationException (or a wrapper around FormRequest::failedValidation) that emits a structured log line with form name, field, rule, and a hashed user/session identifier is roughly 100–200 lines. You control the schema, the PII handling, and the retention policy.
• If you need maintained tooling: look at modern Symfony bundles for form/validation logging, or route errors into your existing observability stack (Sentry breadcrumbs, OpenTelemetry spans, structured logs to your warehouse). A generic logging pipeline is more durable than a form-specific bundle.
• If your real need is product analytics rather than debugging: a client-side or edge-layer capture of validation events will give you session context the server never sees, and won't require touching PHP at all.

Treat this repository as documentation of an idea, not as a component. Read the listener, understand the hook point, and reimplement.

How to Pitch It (Stakeholders)

Executive summary: We evaluated lendable/form-error-log-bundle, a 2017-era Symfony bundle that logs form validation errors for usability analysis. Recommendation: do not adopt. It is archived, unmaintained, has no dependents, and is built for Symfony — it does not work with our Laravel stack. The underlying idea, however, is worth pursuing.

The opportunity is the instrument, not the package. Today we measure form completions but not form failures, which means we are blind to the most common reason users abandon a flow. Instrumenting validation errors gives us a per-field failure ranking for a few days of engineering effort, and that ranking is directly actionable against checkout and signup conversion.

Ask: approve a small, time-boxed engineering task (~2–3 days including schema design and a dashboard tile) to build equivalent telemetry natively in Laravel, with explicit PII scrubbing and a defined retention window. Expected outcome is a ranked list of the top failing fields within two weeks of data collection, feeding the next planning cycle.

Risks to flag: validation error payloads can contain user-entered PII, so the log schema must be agreed with security/legal before launch; and without a sampling or aggregation strategy, volume at peak could be significant. Both are solvable in the build and are not reasons to skip it.

Bottom line for engineering: the bundle is a 150-line reference, not a dependency. Don't vendor it. Spend the afternoon writing our own — we'll get better framework fit, better data hygiene, and code we can actually maintain.