Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Jsformvalidator Bundle

Jsformvalidator Bundle Laravel Package

shopsys/jsformvalidator-bundle

A Symfony bundle from Shopsys that adds client-side JavaScript form validation by translating server-side constraints into instant browser feedback. It helps build responsive forms with consistent rules, customizable messages, and fewer validation round trips.

View on GitHub
Deep Wiki
Context7

Javascript validation for Symfony forms.

Frequently asked questions about Jsformvalidator Bundle
Is shopsys/jsformvalidator-bundle compatible with Laravel?
No. This is a Symfony bundle that hooks into the Symfony kernel through a DI extension, a Bundle class, and form-type extensions, and it emits validation metadata at Twig render time. None of those contracts exist in Laravel, and there is no Laravel bridge or framework-agnostic core. Laravel teams should instead generate a rules object or JSON Schema from FormRequest rules and feed that to a JavaScript validator.
How do I install shopsys/jsformvalidator-bundle?
Install it with Composer, then register the bundle in your Symfony application's bundle configuration. Enable validation per form using the bundle's form option or configuration, and make sure your asset pipeline such as Webpack Encore or Vite bundles the shipped client-side JavaScript assets. The real effort is auditing which of your constraints have JavaScript equivalents, not the installation itself.
Which Symfony versions does version 2.0 of this bundle support?
The 2.0.0 release notes explicitly add Symfony 6 and Symfony 7 support, which materially de-risks the near-term upgrade path. However, the changelog is a single line with no backward-compatibility list and no stated drop of Symfony 4/5 or older PHP versions. Check the composer.json constraints directly before running composer update, and if you are on Symfony 5.4 confirm support or stay pinned to 1.7.x.
How does the bundle generate JavaScript validation rules from Symfony forms?
It reads your Symfony form types and their constraints and projects them into client-side validation metadata when the form is rendered in Twig. The same PHP constraint definitions are therefore reused for both browser and server checks, so rules are defined once. Twig helpers render the validation metadata into the template where the JavaScript validator picks it up.
Does client-side validation replace server-side validation?
No, the server must remain the sole source of truth. Constraints that have no JavaScript counterpart, such as UniqueEntity, Callback, Expression, entity-backed checks, and custom validators, silently produce no client-side check. Treat the browser validation strictly as a UX latency reduction and never as a security or integrity control.
Can I use custom constraints and translatable error messages with it?
Yes. The bundle supports custom constraints and translatable error messages, so messages can follow your existing translation workflow. The catch is that a custom constraint only validates in the browser if you also provide the matching JavaScript-side validator; otherwise it degrades to a server-only check.
Does it work with Stimulus, Turbo, or Symfony UX forms?
Expect friction. The JsFormValidator lineage assumes a jQuery-era asset stack and predates Symfony UX Form conventions, so Stimulus and Turbo front-ends will likely need shimming. The 2.0.0 release notes mention framework support only, with no front-end modernisation, so this risk is unchanged.
Is this bundle useful for API-only or headless Symfony applications?
No. The constraint-to-JavaScript emission is coupled to server-side form rendering through Twig, so API-first, headless, and JSON-payload architectures get no benefit. There is no headless or JSON mode in the package. If you render forms as JSON, generate a rules object yourself and feed a JavaScript validator directly.
Is shopsys/jsformvalidator-bundle actively maintained, and what is the fork risk?
It is an internal vendor fork of karser/JsFormValidatorBundle maintained to serve the Shopsys Platform, and it has effectively zero external dependents. The 2.0.0 release is a mildly positive maintenance signal that someone is actively working the repository, but it does not create an independent roadmap or a third-party ecosystem. If Shopsys drops it, you own the maintenance.
What are the alternatives to this bundle for client-side form validation?
On Symfony, use native HTML5 constraints plus a JavaScript validator fed by a generated rules object or JSON Schema, optionally alongside Symfony UX form features. On Laravel, derive a rules object or JSON Schema from FormRequest rules and pass it to a JavaScript validator, keeping the server as the source of truth. This bundle is out of scope for Laravel because integrating it would mean reimplementing the concept rather than depending on the package.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core