- Does j-ben87/parsley-bundle work with Laravel?
- No. Despite appearing in PHP package catalogs that often lean Laravel, parsley-bundle is a Symfony bundle: it reads symfony/validator constraint metadata off form types and emits data-parsley-* attributes at render time through Twig form themes. Laravel has no bundle concept and does not model validation as constraint metadata, so the input this package transforms simply does not exist in an Illuminate application. This is not a shim-able gap — the metadata source is absent.
- How do I install ParsleyBundle in a Symfony project?
- Install it with composer require j-ben87/parsley-bundle, register the bundle in your kernel or bundles.php, and make sure Parsley.js is loaded on pages where your forms render. For most projects it is configuration-free, and data-parsley attributes appear as soon as your form types carry supported constraints. You still need to load jQuery and Parsley yourself through your asset pipeline.
- Which Symfony constraints does ParsleyBundle convert into Parsley attributes?
- The documented set includes NotBlank, Length, Email, Regex and Range, plus an extension point for custom constraint-to-Parsley mappings. Coverage is not exhaustive: Symfony also has Choice, Collection, Valid, When and Callback constraints, and any constraint without a mapping is silently skipped. Build an explicit coverage table for the constraints your forms actually use before trusting client-side parity.
- How do I get Parsley-style client validation in Laravel?
- Port the mapping idea rather than the package: write a small internal package that turns the rules array already declared on your FormRequest into data-parsley attributes. A @parsley Blade directive or a ParsleyAttributes::fromRules(array $rules) helper covers most needs, backed by a table-driven test per rule type. Expect roughly three to five engineer-days including the test matrix.
- Is ParsleyBundle actively maintained?
- The signals are weak: around 14 stars, zero dependents, a single maintainer, and a last release in December 2023 with a composite score near 0.37. A bus factor of one with no downstream users means breakage surfaces in your application first. If you adopt it, plan to own and maintain a fork indefinitely.
- Does ParsleyBundle handle validation groups, nested Valid constraints, and conditional constraints?
- Not fully, and the gap is structural rather than a short bug list. Validation groups, nested Valid traversal, When conditions and callback constraints do not translate cleanly into static client-side attributes, so client parity is inherently partial. The dangerous case is a constraint that silently no-ops, making a rule look enforced when the browser never checks it.
- Do I need jQuery to use Parsley.js with Symfony forms?
- Yes. Parsley is a jQuery plugin, so adopting it adds jQuery as a transitive requirement on every page that renders these attributes. On a component-driven front end such as Vue, React, Alpine or Livewire that is a standards tax worth justifying explicitly. Schema-driven validation libraries like Zod or Yup are usually the better architectural fit there.
- Is it safe to render constraint messages as data-parsley attributes?
- The output is HTML attributes containing constraint messages and option values, which is an attribute-injection vector if interpolation is unescaped. The package has no published security review, so treat its escaping path as unproven until you check it yourself. Add a test that renders a message containing quotes and angle brackets and asserts the attribute stays intact.
- What are the alternatives to ParsleyBundle for client-side form validation?
- On Symfony you can hand-write data-parsley attributes, rely on native HTML5 constraint validation, or map constraints yourself inside a form theme. On Laravel, derive attributes from your FormRequest rules or use a schema library such as Zod or Yup on the front end. All of these avoid taking on a single-maintainer Symfony bundle as a dependency.
- Which validation rules can't be enforced client-side with Parsley?
- Any rule that depends on server state: uniqueness checks, rate limits, entitlement checks, and cross-field lookups against the database. Those must be explicitly classified as server-only before anyone assumes client parity with the Symfony constraints. Documenting that split up front prevents the false confidence that generated client-side attributes tend to create.