ikselll/jquery-validation-bundle
A Laravel/PHP bundle that integrates jQuery Validation, bundling client-side form validation assets and helpers so you can add validation rules to your forms and views with less setup.
This bundle targets Symfony 2 (originally released around October 2016), so treat it as a legacy artifact — pin your Symfony version and expect to audit the source before relying on it. Community usage is effectively nil (0 stars, 0 dependents), so the README is your only documentation. A 1.2.2 patch has since landed adding docs, PSR fixes, strong typing, and — most relevant — inheritance of parent form constraints, but that is a light maintenance pulse, not a revival. Read Resources/config/, the bundle's DependencyInjection/ extension, and any Form/ or Twig/ directory first to determine whether it works via a form theme, a form type extension, or a Twig helper.
Minimal path:
composer require ikselll/jquery-validation-bundle
// app/AppKernel.php
new ikselll\JQueryValidationBundle\IkselllJQueryValidationBundle(),
Then load any bundle config and assets (check Resources/public/ or whether it expects you to supply jQuery and jquery-validation yourself):
{% block javascripts %}
<script src="{{ asset('bundles/iksellljqueryvalidation/js/jquery.validate.min.js') }}"></script>
{% javascripts '@IkselllJQueryValidationBundle/Resources/public/js/*' %}{% endjavascripts %}
{% endblock %}
Your first use case should be a single simple form — a registration or contact form — where you render a Symfony FormType, load the bundle's JS, and confirm that required/email/length constraints from the form's constraints option are mirrored as client-side rules. With 1.2.2, also confirm that constraints declared on a parent form type (via inheritance) are now picked up. If nothing is injected into the markup, look for a data-* attribute convention or a form theme you need to register in config.yml under twig.form.resources.
Constraint mirroring. The point of this class of bundle is to translate Assert\NotBlank, Assert\Email, Assert\Length, etc. into jQuery Validation rules. Build your forms with real constraints rather than hardcoding rules in JS — that way server-side validation remains the source of truth and the client is a UX layer, not a security layer.
Parent constraint inheritance (new in 1.2.2). If you compose forms via inheritance (a BaseType extended by concrete types), constraints declared on the parent are now surfaced as client-side rules. This makes the reusable base-form pattern below more powerful: put shared constraints on the parent and they propagate automatically.
Form type extension / theme. If the bundle ships a form type extension, it will typically append attributes like data-validation-rules or classes on the generated <input>. If it instead ships a form theme, register it once:
twig:
form:
resources:
- 'IkselllJQueryValidationBundle:Form:fields.html.twig'
Then all ->add() fields inherit the rendering automatically — consistent and low-friction for teams.
Custom rules. For rules the bundle doesn't map (e.g. password confirmation, phone formats), attach them explicitly in your page script after the form auto-validation initializes, using jQuery Validation's rules option, or add a data- attribute your own template reads. Keep custom rules in a single JS file per feature so they don't get lost in templates.
Remote/AJAX rules. If you need uniqueness checks (email already taken), use the remote rule pointing at a Symfony controller that returns true/false. Return JSON and set dataType: 'json'; the bundle won't do this for you.
Reusable base form. Because this bundle is thin, encapsulate your convention in an abstract BaseType that sets attr defaults and a shared JS partial, plus your shared constraints (now mirrored on the client thanks to 1.2.2's parent-constraint support), so every new form behaves identically without re-reading the bundle docs each time.
1.2.2 is a maintenance patch, not a modernization. There is still no guaranteed PHP 7.2+ / Symfony 3+ compatibility. If you're on Symfony 3.4 LTS or later, test AppKernel registration and the DI extension first; if it breaks, the compiler pass is usually the fix, not the form logic. Consider forking — the surface area is small.composer.json's php constraint after composer update; if you're still on PHP 5.x/early 7.x this patch could fail to load.composer dump-autoload and a smoke test after upgrading.jquery.validate.js expects; mismatches produce silent no-op validation (form submits, nothing validates).$('#yourForm').data('validator') exists after load, and that your form selector matches — Symfony's form naming (form_name_field) is a common culprit. This is the first thing to check when the new parent-constraint behavior "doesn't work."$form->isValid() as the gate.GET; make sure it's exempt from CSRF if you use the form token, or you'll see 419/403 errors surfacing as validation failures.messages_xx.min.js from jquery-validation or override with a messages map; otherwise users see the default "This field is required."composer.json (e.g. lock to 1.2.2), add a comment pointing at the repo URL, and note in your team wiki that the bundle is effectively unmaintained so the next developer doesn't discover it the hard way.How can I help you explore Laravel packages today?