Parsley Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for validation parity. The bundle's only real value is DRY: Symfony Validator constraints become Parsley data-parsley-* attributes automatically, so the server rule set is the single source of truth and nobody hand-maintains a second copy in the browser. The decision this informs is whether that deduplication justifies a third-party dependency versus a ~300-line in-house form-type/Twig extension. For a Laravel team the answer is already "build" — the package reads an input schema (symfony/validator constraint metadata) that Laravel does not produce.

• Where to spend the next form-funnel sprint. Inline, pre-submit validation is a cheap, well-understood lever on signup, checkout, and multi-step wizards. If your analytics show server-side-only validation failures as a drop-off point, this is a low-cost experiment to justify. The package supports the implementation, not the measurement — pair it with instrumentation on validation-error rate per session and abandonment step, or you will never know if it worked.

• Scope negotiation on "validation everywhere." The bundle maps a bounded subset of constraints (NotBlank, Length, Email, Regex, Range-class rules). That limit is a feature: it forces an explicit decision per rule — client-side UX affordance vs. server-authoritative check — instead of the usual hand-wave. Use it to get a signed-off coverage table before any code lands.

• Framework fit as a gating decision, not a detail. This is a Symfony bundle, listed in a Laravel context. In a Laravel-first org the decision it supports is "do not adopt; borrow the pattern." The real comparators are Laravel-native options: Livewire/Inertia error propagation, a Blade directive that emits attributes from a FormRequest::rules() array, or a schema-driven client library (Zod/Yup) generated from a shared contract.

• Dependency posture review. 14 stars, 0 dependents, single maintainer, last release December 2023, composite score 0.37. That is enough signal to make "are we willing to own an effectively unmaintained dependency in a user-facing path?" an explicit, written decision rather than an accident discovered six months later.

• Roadmap sequencing. Because it is additive (attribute emission at render time, nothing authoritative), it can be piloted behind a flag on one low-risk form family without blocking a platform upgrade — provided you accept fork ownership if you keep it.

When to Consider This Package

Consider it when:

• The stack is genuinely Symfony — Form component plus Validator constraints as the source of truth — and the front end already loads Parsley/jQuery. In that case the bundle is additive, not a new runtime dependency, and time-to-first-attribute is measured in hours.
• You need a fast, low-effort win on an existing form-heavy app where replacing the front end (Livewire, Inertia, Vue/React) is out of scope for this cycle.
• Your rules are overwhelmingly synchronous and stateless — required, length, email, regex, numeric range — and map cleanly to Parsley validators.
• You accept fork-and-own risk: MIT license means you can vendor, patch, and pin it. For something this small, that is the only responsible posture.

Look elsewhere when:

• You are on Laravel. The constraints this bundle introspects do not exist in a standard Laravel app; Illuminate\Validation is a separate rule system. Adoption cost approaches rewrite cost, and a shim would still leave you maintaining a fork. Port the mapping idea instead.
• The front end is component-driven (Vue, React, Alpine, Livewire). Attribute-driven jQuery validation is the wrong architecture; schema-driven validation generated from a shared contract is the better bet.
• Rules require server state — uniqueness, rate limits, entitlement checks, cross-entity lookups. Client-side parity here is a trap: false confidence plus duplicated business logic.
• You need maintained upstream. No releases since Dec 2023 and zero dependents means no community pressure to catch Symfony or Parsley compatibility breaks. Aggressive platform upgrade cadence = you own the maintenance.
• Any stakeholder reads "validation" as a security control. Client-side validation is a UX affordance only. Correct that framing before adoption, not after.

How to Pitch It (Stakeholders)

To executives. This is a small, free, MIT-licensed utility that removes duplicated work in form validation: instead of writing the same rules twice — once on the server, once in the browser — it derives the browser rules from the server rules automatically. The business upside is faster, friendlier forms; users see mistakes before they hit submit, which typically reduces abandonment on signup and checkout. Two honest caveats. First, the project is very small — 14 stars, no downstream users, last release over a year ago — so if we keep it, we own it. Second, and more important for us, it is built for Symfony, not Laravel; our validation layer emits a different rule format that this package cannot read. The recommendation is therefore: for a Symfony codebase, run a scoped pilot on one or two forms; for our Laravel codebase, treat it as a design reference and spend three to five engineer-days implementing the same idea natively against our own validation rules. Cost either way is near zero; the real cost is ownership.

To engineering.

• What it does: reads Symfony Validator constraints off form types and emits matching Parsley data-parsley-* attributes in rendered markup, keeping client and server rules in sync from one declaration.
• What it does not do: it is not a client validator (Parsley is), it does not cover constraints without a Parsley equivalent, it does not touch async or server-state rules, and it is not a security boundary.
• For us specifically: the value is the constraint→attribute mapping table and the escaping logic — roughly a few hundred lines. The metadata reading, DI wiring, and Twig integration are Symfony-coupled and would be discarded. Build a small internal equivalent: a ParsleyAttributes::fromRules(array $rules) helper or a Blade directive over FormRequest::rules(), table-driven tests per rule type.
• Adoption shape (if a Symfony surface exists): vendor or fork, pin the version, ship behind a feature flag on one form family, leave server-side validation untouched as the authority.
• Exit criteria: if validation failures per session or form abandonment measurably drop, keep and maintain; if not, remove the Parsley runtime — rollback is clean because nothing authoritative lives in the package.
• Non-negotiable guardrails: never remove or relax server constraints; audit the mapping for rules that silently fail to convert (a rule that emits nothing is invisible and is the failure mode most likely to bite us); confirm CSP, accessibility (error announcement, aria-invalid), and no-JS fallback before rollout; and verify attribute escaping, since constraint messages and option values are interpolated into HTML attributes.