it/input-mask-bundle
Symfony bundle that adds client-side input masking to form fields, with Twig helpers and asset integration for common masks such as phone numbers, dates and currency. It simplifies wiring mask scripts into templates, though it is a small, lightly maintained package with limited adoption.
Architecture fit — poor for Laravel, and the framing needs correcting. Despite the "Laravel/PHP package" label, it/input-mask-bundle is a Symfony bundle, not a Laravel package. It registers form types against Symfony\Component\Form\AbstractType, ships Twig templates, and wires itself through the Symfony DI container and bundle registration. Laravel has no equivalent bundle discovery mechanism; Illuminate's Form component was removed in Laravel 5, and Blade has no form-type abstraction. There is no architectural seam to hook into — adopting this in a Laravel codebase means porting it, not installing it.
What it actually does. It is a thin convenience layer: Symfony form types that emit data-inputmask attributes and initialise the RobinHerbots/Inputmask jQuery plugin. All real masking logic lives in the jQuery plugin. The bundle contributes configuration ergonomics (declaring a mask alongside a field definition) and nothing else — no server-side normalisation, no validation, no storage contract.
Integration feasibility — low. Three compounding blockers:
symfony/form ^2.7|^3.0. Laravel 10/11 requires PHP 8.1+, and Composer will either refuse to resolve or require --ignore-platform-reqs hacks.getName(), removed in Symfony 3.0 — evidence the code was never modernised.Technical risk — high, concentrated in abandonment rather than exploitability. No security surface to speak of (it handles no data server-side), but: last release 2017-06-05, 8 stars, 0 dependents, score 0.19. Zero dependents is the signal that matters — no downstream project has validated this against any framework version in seven years. You would be the sole maintainer of a fork on day one.
Key questions before any decision:
x-mask covers this natively in ~1 line.Verdict: Reject as a dependency. The pattern (declare mask once, emit as data attribute, attach client behaviour) is worth copying; the code is not.
Stack fit. None for Laravel. For a Symfony 3.x application already on jQuery, it would drop in cleanly — but that describes almost no active codebase in 2025.
Recommended path — reimplement the pattern, not the package. The concept decomposes into four framework-agnostic pieces:
config/input-masks.php) defining named masks: phone_us, postal_uk, iban, etc. Single source of truth, shared by frontend and backend.<x-input name="phone" mask="phone_us" /> renders data-mask="phone_us" plus inputmode="tel" and a pattern attribute for no-JS fallback.inputmask npm build (RobinHerbots' plugin has shipped a jQuery-free distribution for years) or Alpine's x-mask. No jQuery.Masked validation rule and a Cast/mutator that strips formatting to a canonical value before persistence.Step 4 is where this package adds no value and where most production incidents originate, so budget accordingly.
Migration path if already using the bundle (Symfony context): extract mask definitions from form-type configuration into a neutral config file, replace form types with a Twig macro or form extension emitting the same data attributes, then drop the bundle. Low effort — the surface is small.
Compatibility notes. If the vanilla inputmask npm package is used, verify Vite/Rollup ESM interop; the plugin historically shipped UMD. Watch CSP: bundle-era initialisation used inline <script> blocks, which will fail under a strict script-src. Prefer data-* attributes plus a delegated listener.
Sequencing. (a) Agree the canonical-value contract and validation rules first — this is a data-model decision, not a UI one. (b) Build the config registry. (c) Ship the Blade/component + adapter behind a feature flag on one low-risk form. (d) Add normalisation on write with a backfill check for existing malformed records. (e) Roll out, then retire any legacy masking JS.
Maintenance. Adopting the bundle means inheriting an unmaintained 2017 dependency with no upstream. Reimplementing is roughly 100–150 lines of code you fully control. The maintenance delta strongly favours reimplementation even ignoring the framework mismatch.
Support. 8 stars, 0 dependents, no release in seven-plus years. There is no community to escalate to, no issue history that reflects modern PHP, and no security advisory feed. Internal ownership must be assigned explicitly if forked.
Scaling. Negligible — masking is client-side presentation, no runtime throughput cost, no infrastructure footprint. The scaling concern is organisational: mask definitions drift across forms without a registry, producing inconsistent data quality that surfaces later in reporting and integrations.
Failure modes to design against:
"(555) 123-4567" stored in a phone column instead of 5551234567 — breaks search, dedupe, and downstream APIs. This is the highest-probability, highest-cost failure and the bundle does nothing to prevent it.inputmode="text" degrade UX; multi-byte locales can break literal character masks.Ramp-up. Low technically — a mid-level engineer reproduces the capability in under a day. The real ramp-up is domain: agreeing canonical formats per field and auditing existing dirty data. Budget most of the effort there, not in the frontend.
Bottom line. With a composite score of 0.19 and an opportunity score of 14.5, this package sits at the bottom of the evaluation range, and the framework mismatch makes it inapplicable to the stated Laravel context regardless. Recommend closing the evaluation with "adopt alternative — build in-house or use a maintained vanilla masking library" and reallocating the effort to the server-side normalisation problem the bundle leaves unsolved.
How can I help you explore Laravel packages today?