- Is fp/jsformvalidator-bundle a Laravel package?
- No. fp/jsformvalidator-bundle is a Symfony bundle, not a Laravel package. It requires symfony/framework-bundle, registers a Bundle subclass with a DI extension and compiler pass, extends Symfony form types through FormTypeExtension, and ships a Twig template plus the jsformvalidator JavaScript runtime. Laravel has no Symfony Form component, bundle mechanism, or Twig default, so it cannot be installed as a normal Laravel dependency.
- Can I install fp/jsformvalidator-bundle in Laravel 11 or 12?
- Not through Composer as a Laravel package. Any Laravel use is a build project, not an install: you would vendor only the client-side jsformvalidator runtime and write a Laravel-side serializer that maps FormRequest rules and Rule objects into the runtime's constraint-to-rule JSON contract. The PHP half of the bundle, including the Symfony bundle wiring and form extensions, is not reusable in Laravel.
- What Laravel and PHP versions does fp/jsformvalidator-bundle support?
- For Symfony, version 1.8.0 requires PHP 8.4+ and symfony/* ^8.0 with Twig 3. Laravel 11 and 12 commonly run on PHP 8.2+, and most estates are still on PHP 8.2 or 8.3, so the PHP floor blocks direct reuse even if you tried to copy PHP code. The 1.7 line targets Symfony 5.4, 6.4, and 7.x, which creates two maintenance lines.
- How do I install and configure fp/jsformvalidator-bundle in Symfony?
- In Symfony you install it with Composer, enable the bundle in your kernel or bundles configuration, and make minimal Twig template changes so forms emit the generated JavaScript rules. You then use the companion jsformvalidator runtime to consume the serialized constraint graph. There is no equivalent Laravel installation or configuration path.
- What does fp/jsformvalidator-bundle actually generate for client-side validation?
- It generates JavaScript validation rules from existing Symfony form and constraint configuration. The generated rules cover common constraints, custom messages, field-level errors, and AJAX-backed validation for server-dependent checks. The reusable core is the client-side runtime plus the constraint-to-rule JSON payload it consumes.
- How long would it take to integrate fp/jsformvalidator-bundle with Laravel?
- The technical evaluation estimates 3 to 6 engineer-weeks for a credible Laravel MVP covering scalars, required, min/max, email, regex, same/confirmed, and in. Production-grade parity is estimated at 2 to 3 months. That work includes reverse-engineering the payload schema from the JS runtime, writing a Laravel serializer for FormRequest rules and Rule objects, and wiring a Blade or Vite bootstrap.
- Which Laravel validation rules cannot be reproduced by fp/jsformvalidator-bundle?
- Closure rules, custom Rule objects, after and prepareForValidation hooks, unique and exists checks, and sometimes/exclude/bail semantics cannot be fully closed client-side. Those degrade to remote validation or remain server-only, which is where front-end and back-end drift risk lives. There is also rule-surface asymmetry: the new Luhn constraint has no first-party Laravel counterpart, so the client could reject input that the Laravel server accepts.
- Does the fp/jsformvalidator-bundle JavaScript runtime work without a Symfony backend?
- The JS runtime is the only reusable piece, but there is no evidence that the constraint contract is fully documented for zero-Symfony use; it appears implicitly defined by the PHP serializer. Luhn does not have a documented payload shape in the provided material, only a PHP-side serializer emitting it. That leaves schema stability across 1.8.x unclear, and there is no confirmed versioning field in the payload.
- Is fp/jsformvalidator-bundle production-ready and well maintained?
- Treat it as beta-quality with high dormancy risk. Version 1.8.0 is the first stable release and the first semver line, but it has zero 1.8.x patch history after a revival PR burst, single-org concentration, no funded-maintainer signal, 125 stars, and 0 dependents. CI has PHPStan, coverage gates, Cypress tests, and Dependabot, but the absolute suite is small against a wide rule surface and validates PHP 8.4, 8.5, and 8.6 only.
- What are the best alternatives to fp/jsformvalidator-bundle for Laravel?
- For Laravel, use Laravel-native FormRequest validation as the source of truth and pair it with a front-end validator or a Precognition-style approach that calls the backend. If you specifically want the jsformvalidator runtime, vendor it and own the serializer, schema, and tests. Avoid treating fp/jsformvalidator-bundle as a drop-in Laravel dependency.