Weave Code
Symfony Precognition Laravel Package
fundraisingbox/symfony-precognition
Symfony bundle that brings Precognition-style request validation to Symfony apps, letting frontends preview form errors before submission without running the controller, for faster feedback and fewer failed submissions.
fundraisingbox/symfony-precognition brings Laravel-style Precognition to Symfony. It lets frontends validate form data against the same server-side constraints used by your controllers, returning validation errors before the real request executes—so you avoid duplicated validation logic and unnecessary side effects.
- Detects precognition requests and short-circuits controllers when validation passes.
- Reuses Symfony Validator constraints and request DTOs.
- Returns structured JSON validation errors for client-side handling.
- Keeps validation rules in one place across frontend and backend.
- Simple Symfony integration via a request listener.
Frequently asked questions about Symfony Precognition
- Can I use fundraisingbox/symfony-precognition in a Laravel application?
- Not directly. The bundle hooks Symfony's HTTP kernel, controller events, the Symfony Validator component and the DI container, and none of those extension points map onto Laravel's HTTP kernel, FormRequest lifecycle or Illuminate\Validation. Laravel has shipped native Precognition since 10.x via the HandlePrecognitiveRequests middleware and the Precognition and Precognition-Validate-Only headers, so replacing that with an 8-star third-party bundle is not a sensible trade. A Laravel port would require a fork that reimplements the listener against Laravel's pipeline.
- What does this package actually do?
- It is a Symfony integration for Precognition-style request validation. When a request carries the precognition header, the bundle runs the declared validation rules and returns JSON validation results without executing your controller. Your frontend can therefore validate a form against server-side rules before the real submit, while normal requests still hit the controller as usual.
- How do I install and configure it in a Symfony app?
- Install it with Composer as fundraisingbox/symfony-precognition and register the bundle in your Symfony application, then declare the validation rules it should run precognitively. Treat the README as the authoritative source for the exact registration and configuration keys, since the bundle is small and its documentation is the contract. Assume PHP 8.1+ and Symfony 6.4 or 7.x, and verify against your pinned Symfony LTS before committing.
- Does it use the same Precognition headers as Laravel's native implementation?
- That is the first thing to verify in the source, because the bundle may implement Laravel's Precognition and Precognition-Validate-Only header contract or a bespoke one. If the contract diverges, a cross-stack frontend needs two code paths for the same inline validation UX. The pragmatic fix is to normalize headers and the error envelope at your API gateway so clients see one contract regardless of which backend answers.
- What does the bundle return on a successful precognitive request?
- The key question is whether success returns 204 No Content, an empty JSON body, or a partial payload, and whether that shape is stable enough to build a client against. Pin the behaviour with contract tests on your side rather than relying on undocumented responses. If the response format is ambiguous or changes between releases, wrap it at the gateway before exposing it to frontend code.
- How should authorization work when the controller is skipped?
- This is a high-severity concern. Precognitive requests short-circuit before the controller, so any authorization performed inside the controller is skipped too, which can leak validation detail about resources the caller should not touch. Move policies into the validation layer, a kernel listener or Symfony voters, and confirm the bundle exposes an extension point for voters before you rely on it.
- Which Symfony versions are supported and is there a deprecation policy?
- Assume Symfony 6.4 LTS and 7.x, but check the CI matrix in the repository for the authoritative answer. Symfony major-version churn combined with a small maintainer makes version coupling a real risk for long-lived services. If no published support or deprecation policy exists, budget time to pin versions and test upgrades yourself.
- Is this package safe to run in production?
- It is a single-organisation project with roughly 8 stars and no dependents, so there is little ecosystem pressure-testing. The MIT license means you can vendor it or build a thin in-house fork if maintenance lapses; scope that fork now, since it is essentially one listener, one attribute and tests. That keeps your exit cost known instead of discovered during an incident.
- How do I test endpoints that rely on precognitive validation?
- Send requests with the precognition header and assert both the JSON error envelope and that the controller was not executed, for example by asserting no side effects occurred. Also test the normal non-precognitive path so the same rules still run at execution time. Add contract tests around the header names and response shape so a bundle upgrade cannot silently break your frontend.
- What are the alternatives, and how do I keep rules consistent across Laravel and Symfony?
- For Laravel endpoints, use the native Precognition middleware rather than this bundle; adopt the bundle only where a Symfony runtime sits in the request path, such as a Symfony service or back-office behind a Laravel BFF. To avoid drift between the two validation stacks, lift rule declarations into a shared schema such as OpenAPI 3.1 with JSON Schema, or a generated rule manifest, so Laravel FormRequest rules and Symfony constraints derive from one source.
Weaver
How can I help you explore Laravel packages today?