- Is it/input-mask-bundle a Laravel package?
- No. It is a Symfony bundle that registers Symfony form types, Twig templates, and DI container wiring; it does not provide a Laravel service provider, facade, or Blade integration. Laravel removed its Form component in 5.0, so there is no form-type abstraction to hook into. Adopting it in Laravel would mean porting the code, not installing a dependency.
- Can I install it/input-mask-bundle with Composer in a Laravel 10 or 11 app?
- Composer will likely refuse to resolve it because the bundle targets old Symfony and PHP constraints, while Laravel 10 and 11 require PHP 8.1 or newer. Using --ignore-platform-reqs may force installation but does not create an integration path. Even if files land in vendor, Laravel will not discover or boot the Symfony bundle.
- Which Laravel and PHP versions does it/input-mask-bundle support?
- None officially. It was released around 2017 for Symfony 2.7 and 3.x-era applications on PHP 5.5 through 7.x, with form types that use APIs removed in Symfony 3.0. It has no declared Laravel support and is not tested against Laravel 8, 9, 10, or 11.
- Does it/input-mask-bundle require jQuery?
- Yes, the actual masking behaviour comes from the RobinHerbots Inputmask jQuery plugin; the bundle only emits data-inputmask attributes and centralizes mask configuration. Modern Laravel front ends typically use Blade with Vite and vanilla JavaScript, Alpine, Livewire, or Inertia, where adding jQuery just for masking is disproportionate. A jQuery-free inputmask distribution exists if you want the same plugin without jQuery.
- Will it work with Livewire, Inertia, or Alpine-powered forms?
- No, not natively. The bundle renders through Symfony form types and Twig, and initializes a jQuery plugin, so it has no awareness of Livewire lifecycle re-renders, Inertia page components, or Alpine directives. For Alpine, x-mask covers common formats in one attribute; for Livewire, combine Alpine masking with server-side normalization.
- Does it handle server-side validation or normalize phone numbers and dates?
- No. It is presentational only: it enforces format in the browser and provides no server-side normalization, validation, or storage contract. You still need a Laravel validation rule and a mutator or cast that strips formatting and stores a canonical value such as E.164 for phones. That server-side half is where production data-quality incidents usually originate.
- How do I define reusable input masks with it/input-mask-bundle?
- In Symfony you declare mask options alongside form field definitions and render them with the bundle's Twig helpers and assets, keeping named masks centralized. In Laravel there is no equivalent configuration hook, so the practical pattern is a config/input-masks.php registry plus a Blade component that emits data-mask, inputmode, and pattern attributes. That keeps one mask definition shared by front end and back end.
- What are the best Laravel alternatives for input masking?
- Use Alpine's x-mask for simple formats, the vanilla inputmask npm build or imaskjs with Vite for more complex masks, and pair either with a Laravel validation rule and mutator for canonical storage. Livewire forms can combine wire:model with Alpine masking and server-side normalization. Test browser behavior with Laravel Dusk or Playwright and test normalization with PHPUnit feature tests.
- Is it/input-mask-bundle maintained and safe for production?
- It has no meaningful server-side attack surface because all masking happens in the browser, but it is effectively abandoned: the last release was 2017, adoption is tiny, and it has zero dependents. The risk is maintenance and compatibility, not exploitation; you would own a fork from day one. For a production Laravel app, reimplement the pattern rather than depending on the package.
- How do I migrate off it/input-mask-bundle if I already use it?
- Extract the named mask definitions from Symfony form-type configuration into a framework-neutral config file, then replace the form types with a Twig macro or form extension that emits the same data attributes. Swap the jQuery plugin initialization for Alpine x-mask or the vanilla inputmask build, and add server-side normalizing plus validation before persistence. Once the attributes and client adapter are in place, remove the bundle and its jQuery dependency.