laravel-jsvalidation: reusing server side validation rules in the browser, with a jQuery caveat

One rule set, enforced in two places

The package exists to remove a specific duplication. You have validation rules in PHP, and you want the browser to check them too, and the usual outcome is that you write the rules twice and hope they stay in sync.

laravel-jsvalidation lets you reuse your Laravel Validation Rules, Messages, FormRequest and Validators to validate forms automatically on the client side, without writing any JavaScript code or using an HTML Builder Class. The message is that you can validate forms automatically by referencing your defined validations, and that the messages are loaded from your validations and translated according to your localization preferences.

The FormRequest is the entry point the documentation recommends. The easiest way to create JavaScript validations is using Laravel Form Request Validation, and the call is a facade in the view.

{!! JsValidator::formRequest('App\Http\Requests\MyFormRequest') !!}

That single call is the whole integration. The package reads the request class, walks its rules, and emits the corresponding client side checks, with the messages coming from the same place Laravel would use them on a server validation failure.

The consequence is the interesting part. There is one definition of what a valid email is, and it is the one in your FormRequest, so a change to a rule propagates to the browser on the next page load with no second edit. That is the value proposition, and it is a modest, well defined one rather than a framework.

The rules that need a server, and the ones nobody implemented

The README is unusually clear about the boundary between what runs in the browser and what does not, and it is worth reading the list twice.

Almost all the Validation Rules provided by Laravel and other packages are supported, and almost all are validated client side using JavaScript. But in some cases the validation should be done server side via AJAX. The list of those is short and specific: ActiveURL, Unique, Exists, Custom Validation Rules, and validations provided by other packages.

The reason is not hard to guess and the README does not need to spell it out. A uniqueness check cannot be done in the browser, because the browser does not have the database. A custom rule that talks to the server has the same problem. So those rules are sent to the server over AJAX, and the browser waits for the answer, which is a real validation but with a network round trip and a visible latency.

There is a second list, the unsupported ones. Some Laravel validations are not implemented yet: Present, and the DateFormat rule which does not support timezone format.

That second list is the more interesting one for an evaluator, because it is the failure mode you will discover in production rather than in the first hour. The Present rule in particular is the one to think about, since it is what you use to require a field to be submitted even when the field would be considered optional. And a DateFormat rule that silently ignores the timezone part of a format is the kind of gap that produces a validation that passes when the server would fail.

The honest framing is that the package covers the large majority of Laravel's rules and is explicit about the gaps, but the gap list is where your specific application will hit trouble.

The jQuery dependency, and what it means for a modern Laravel stack

The package uses the Jquery Validation Plugin bundled in a provided script, and the documented usage shows exactly what that implies for your page.

<!-- Javascript Requirements -->
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.1/js/bootstrap.min.js"></script>

<!-- Laravel Javascript Validation -->
<script type="text/javascript" src="{{ asset('vendor/jsvalidation/js/jsvalidation.js')}}"></script>

Three script tags. The first is jQuery 2.1.3 from a CDN, the second is Bootstrap 3.3.1 from the same CDN, and the third is the package's own bundled validation script served from your own asset directory at vendor/jsvalidation/js/jsvalidation.js.

The last part of the feature list is about how unobtrusive the integration is. It says the package offers unobtrusive integration and that you can use it without the Laravel Form Builder, which is the point that matters for an application with hand written forms.

But the jQuery dependency deserves a plain statement. A Laravel application in 2026 that has dropped jQuery, or a front end built on a modern framework, cannot use this package without adding jQuery back. That is a real architectural decision rather than a detail, because jQuery 2.1.3 is an old release and the package's own package.json pins jquery-validation at 1.21.0 as a runtime dependency alongside locutus and php-date-formatter.

The features list also mentions supports other validation packages, and AJAX validation for the ActiveURL, Unique and Exists rules, for custom validation rules, and for other validation packages. So the package is not closed to the ecosystem, it just is not framework agnostic about JavaScript.

Two build systems in one repository, and a bundle size budget

The repository contains both a PHP package and a JavaScript asset pipeline, which is why the top level carries a composer.json, a package.json, a gulpfile.mjs and a phpunit.xml.dist side by side.

The JavaScript side is a Gulp build. The build script is gulp build, and the dev dependencies are a full Gulp toolchain with gulp-concat, gulp-filter, gulp-rename, gulp-sourcemaps and gulp-uglify, plus webpack and webpack-stream, babel with its presets, and del.

The three runtime dependencies are what the browser actually gets: jquery-validation at 1.21.0, locutus at 2.0.32, and php-date-formatter at 1.3.7. The third of those is the interesting one, because a PHP date formatter running in the browser is how the package reproduces PHP's date parsing semantics in JavaScript, which is what lets a DateFormat rule behave the same on both sides. Locutus is the PHP function port library in JavaScript, used for the same reason, to give the browser PHP's string and array function behaviour.

That design decision is the reason the package works at all, and it is also its main constraint. Reproducing PHP semantics in the browser means the browser side is a port rather than a reimplementation, so any difference between the port and the current PHP version shows up as a validation difference between client and server.

The package also has a bundle size budget, which is unusual to see and worth mentioning because it tells you the maintainer cares about the payload. The bundlewatch configuration sets a maximum size of 25kB for the minified files matching public/js/*.min.js, and there is a bundlewatch script to check it.

The rest of the repository is standard: config/ for the package configuration, resources/ and public/ for the shipped assets, src/ for the PHP source, tests/ for the PHPUnit suite, and a .hound.yml, .styleci.yml, .javascript-style.json and .jshintignore for the various style checkers this project has accumulated over its years.

Supported versions, and the age of the install path

The supported versions are stated plainly: PHP 8.2 to 8.4, and Laravel 11.x to 13.x. That is a narrow and current range, and it is worth noting that the rule and documentation links in the README still point at the Laravel 5.4 documentation, which is a leftover from the early years of the package.

The install itself is delegated to a wiki page. The installation section says to follow the Installation Guide to install the package, and adds that the default config should work out of the box. There is no composer require command in the README, so the exact command is on the Installation Guide page in the project wiki.

The documentation structure is wiki based overall. The Basic Usage page and the Validating-Examples page cover the usage patterns, the Project Wiki home is the main documentation entry point, and there is a separate Facade page for the JsValidator facade. The contributing guide is also in the wiki.

That structure is the main practical difference between this package and a modern one. A Laravel package published in 2026 would normally ship its documentation with the code, searchable and versioned with the release. Here the documentation lives in a wiki, and a wiki is not versioned with the code, so a page that describes v4 behaviour may be edited after v5 changes. For a package that has been releasing for years, that is a real risk when you are following an error message.

The changelog is the exception, and it is a good one. The CHANGELOG.md is in the repository and is pointed at from the README for what has changed recently, so the history is at least versioned even when the prose documentation is not.

Against writing the rules twice, and against a modern front end stack

Two comparisons, and the second one decides the outcome for a lot of teams.

The first is against writing the validation twice yourself. That approach costs you one JavaScript file per form, and it costs you a bug every time a rule changes on the server and not in the browser. The package removes both costs, and it removes the translation problem too, because the messages come from your Laravel localisation files. For an application with many forms, or with a team that cares about the messages being right in the user's language, that is worth a dependency.

The second is against a modern front end stack. If your forms are React or Vue, you are already running a validation layer on the client, and the modern options there are schema based validation that shares a definition with the server, or simply accepting that the client is a convenience and the server is the authority. The package is built for server rendered Laravel views, and its output is a jQuery plugin configuration plus HTML attributes on your inputs, which is exactly the right shape for Blade and the wrong shape for a component based front end.

The third comparison is the simplest one. If your application has three forms with four fields each, this package is overkill and the duplication is manageable. The value scales with the number of forms and with the complexity of the rules, and it is highest exactly where the rules are shared with other parts of the system, which is what the FormRequest approach is for.

So the decision is roughly: a Laravel application with server rendered forms, jQuery still in the page, and enough forms that duplicating the rules has started to cost you. If any of those three is false, there is a smaller answer.

Editorial conclusion

laravel-jsvalidation fits a Laravel team that has already written its validation rules and messages and wants the browser to enforce the same constraints, with one facade call in the view instead of a second implementation in JavaScript. It does not fit a team that has moved away from jQuery, since the package bundles the jQuery Validation Plugin and the documented usage pulls jQuery from a CDN, and it does not fit a project whose forms rely on rules the package has not implemented, such as present and DateFormat with a timezone. Check three things before you commit. Check your Laravel and PHP versions against the stated support, which is PHP 8.2 to 8.4 and Laravel 11.x to 13.x. Check the rule coverage, because almost all Laravel rules are validated client side but several are deliberately not, and the package lists what is not implemented. And check how the messages are produced, because the translation follows your Laravel localization preferences, which means the validation text has to exist in the locale files your users actually select. The last push was on 2026-05-22, the newest release listed is v4.10.3 from 2026-03-17, and the license is MIT.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. proengsoft/laravel-jsvalidation on GitHub
4. README
5. Releases