Formlogger Bundle Laravel Package

Technical Evaluation

Framing: The request is scoped as a Laravel package evaluation, but shark/formlogger-bundle is a Symfony 2 bundle distributed under the shark/ namespace. That is the first and largest TPM finding: the question "how do we leverage this in Laravel?" has no defensible answer at the package level. What is portable is the capability — automatic capture of form submissions and validation errors into a PSR-3 logger — not the code.

• Architecture fit — not applicable to Laravel. The bundle is coupled to Symfony's HttpKernel, DI container, and Form component. It registers a service definition / compiler pass and subscribes to FormEvents (likely POST_SUBMIT) to serialize FormInterface data and FormErrorIterator output. Laravel's validation surface is Illuminate\Validation\Validator, FormRequest, and ValidationException — there is no persistent form object and no post-submit form event to hook. There is no shared contract to adapt against.
• Integration feasibility — low, and not worth pursuing. No Laravel package discovery, service provider, facade, or publishable config. Adopting it would pull Symfony 2 components (symfony/form, symfony/http-kernel, symfony/dependency-injection, symfony/event-dispatcher) alongside Illuminate, producing duplicate event dispatchers and version conflicts. Reaching parity would mean booting a Symfony kernel or hand-wiring a Symfony dispatcher purely to feed a logger — disproportionate effort for what is functionally tens of lines of Laravel code.
• Technical risk — high.
  • Abandonment: 10 stars, 0 dependents, score 0.11, no visible security-response process. Any CVE in the Symfony 2 chain becomes ours to patch.
  • EOL runtime: Symfony 2 reached end of life in 2019 (2.8 was the last LTS). Symfony 2-era bundles typically declare php >=5.3 with no upper bound and predate modern PSR-4/type hygiene; PHP 8.2+ compatibility is unlikely without patches.
  • Data-handling: the product's entire purpose is persisting raw form values plus error messages. That is a PII/secret-exposure surface (passwords, tokens, card and health fields) into logs by default, with no evidence of redaction. This is a compliance issue before it is a technical one.
  • Log-injection / volume: unstructured serialized payloads, unbounded record size, and potential log-volume blowups on high-error endpoints.
• Key questions for the requester:
  1. Is the underlying requirement error-rate visibility, a debugging aid, or an audit trail? Each maps to a different Laravel-native solution (log channel plus ValidationException listener, Telescope/Sentry, or an audit table).
  2. Is there any Symfony 2 surface in the estate at all, or is this a mis-scoped scanner suggestion? (0 dependents suggests the latter.)
  3. Which fields must be redacted, and what retention / access-control policy applies to captured submissions?
  4. Are we prepared to fork and own a Symfony 2 dependency indefinitely? If yes, the cost almost certainly exceeds a native reimplementation.

TPM verdict: Do not adopt as a strategic dependency. Record the capability requirement, satisfy it natively, and close the request as "not applicable to our stack."

Integration Approach

• Stack fit — none. Our stack is Laravel/PHP with Illuminate components; the bundle targets Symfony 2's kernel and DI container. There is no bridge contract, and the only literal integration path is hosting a second framework runtime, which is not a defensible design choice for a logging feature.
• Recommended approach — reimplement natively in Laravel. The behavioral specification is small and fully understood:
  • A FormSubmissionLogger listener subscribed to application events, or — more directly — a global middleware or exception-handler hook that catches ValidationException.
  • A FormRequest base class/trait that emits a structured event on validation failure.
  • A dedicated log channel in config/logging.php (JSON formatter, daily driver) with an explicit allowlist of captured fields for redaction.
  • Optional structured sink (Sentry breadcrumb, or a form_errors table) only if trend analysis is the real goal.
  • Effort estimate: 1–2 days including tests, redaction, and configuration — cheaper than evaluating and forking this bundle.
• Migration path — greenfield. There are no dependents and no existing adoption to migrate from. If a team has already prototyped with the bundle, the migration is a straight replacement of its logging call sites with the native listener; the only data decision is whether to retain historical log records (recommend no).
• Compatibility (only if pursued anyway). Pin Symfony 2.8 components in an isolated namespace, verify PHP-version constraints against our runtime, ensure the Symfony EventDispatcher does not collide with Illuminate's dispatcher bindings, and confirm no symfony/http-kernel autoload conflict. Realistically incompatible without a shim we would have to write and own.
• Sequencing.
  1. Confirm the underlying requirement and its business owner.
  2. Prototype the native Laravel listener against one high-value form (e.g., checkout or registration).
  3. Define redaction and retention policy before any data is captured.
  4. Roll out behind a per-form config flag; measure volume and signal quality.
  5. Revisit the third-party bundle only if a genuine Symfony 2 service appears — and even then, prefer an HTTP/queue boundary over shared code.

Operational Impact

• Maintenance. Effectively zero upstream maintenance. Adoption means forking the bundle, its Symfony 2 transitive dependencies, and all future security patching — a permanent tax on a component whose functionality is a few dozen lines in our own idiom. That is an unfavorable trade against a natively owned implementation.
• Support. No vendor, no active maintainer, no issue triage, no community (0 dependents). Internal knowledge of Symfony 2 form internals is a shrinking, expensive skill set; we should not add a dependency that requires it.
• Scaling. The logging path itself is a synchronous write on form submission and is not a scaling concern in isolation. The real risks are volume and record size: capturing full payloads and error structures on every invalid submission materially amplifies log storage on high-traffic forms and can add latency if the handler blocks. Any implementation needs sampling, size caps, and async handling.
• Failure modes.
  • Request-path breakage: an exception inside the form subscriber can surface as a 500 on submission rather than a validation response — the worst possible outcome on a conversion-critical path. It must be wrapped in try/catch and never influence the response.
  • Silent data loss: logger misconfiguration or a full disk causes invisible feature failure; the capability needs its own health signal.
  • PII leakage: passwords, tokens, card data, and health/financial fields landing in logs; requires allowlist-based capture, not denylist.
  • Log injection / parsing: unstructured serialized objects break downstream ingestion and can be manipulated via crafted input.
  • Version drift: a PHP or Laravel upgrade breaks a transitive Symfony 2 component with no upstream fix available.
• Ramp-up. Reading the bundle is quick, but onboarding a Laravel engineer onto Symfony 2 DI and form-event semantics is disproportionate to the value delivered. The native alternative is immediately legible to any Laravel developer on the team — the strongest single argument in its favor.

TPM recommendation: Do not adopt shark/formlogger-bundle. Capture the underlying requirement — form-failure observability with PII redaction and sampling — satisfy it with a small native Laravel listener plus a redacted structured log channel, and close the dependency request as "not applicable to our stack." The value is in the capability, not the package.