- Can I use mpetrini/intl-tel-input-bundle in a Laravel application?
- Technically you can require it with Composer, but it will not give you what you expect. The package is a Symfony 4 bundle built around Symfony's Form component, Twig form themes, and bundle registration, none of which Laravel uses. The value it delivers, Symfony form type integration, does not transfer to Laravel. For a Laravel app, install the upstream intl-tel-input npm package and wire it through Vite instead.
- Does this package provide Blade components or Laravel form helpers?
- No. It ships Symfony form types and Twig templates, not Blade views or Laravel validation rules. There is no service provider, config publishing, or facade aimed at Laravel. You would have to rewrite the Twig markup as a Blade component and reimplement any server-side handling yourself.
- How do I add an international phone input with country flags to a Laravel form?
- Install the upstream intl-tel-input package with npm, import its CSS and JS in your Vite entry point, and initialize it on a tel input inside a Blade component. Add hidden inputs for the normalized E.164 value and the selected country ISO code, and keep those in sync on submit. This takes far less effort than porting a Symfony bundle and you control the intl-tel-input version directly.
- Which Laravel and PHP versions does this bundle support?
- There is no Laravel support to speak of, and the package targets Symfony 4 with the PHP constraints that implies. Those constraints are largely irrelevant to a Laravel application and may actively conflict with a modern Laravel install. Check the composer.json on the GitLab repository for the exact Symfony and PHP requirements before considering it at all.
- Does this bundle validate and normalize phone numbers on the server?
- Based on the available description, it adds country flags, automatic formatting, and client-side validation, which is UI behavior rather than authoritative validation. There is no documented server-side normalization to E.164 or country-aware parsing. Treat any client-side result as untrusted and add your own Laravel validation rule plus a phone-number parsing library on the backend.
- Should I store the formatted phone number shown in the input?
- No. The formatted display value is presentation only and can vary by country and user input, so persisting it leads to inconsistent data you cannot reliably query or dial. Store the normalized E.164 value, for example +14155552671, and optionally store the ISO country code alongside it. Send those through hidden inputs or parse the raw field server-side with a library such as libphonenumber for PHP.
- Is mpetrini/intl-tel-input-bundle actively maintained?
- The public signals are weak: no stars, no dependents, a narrow GitLab-hosted package, and a Symfony 4 focus that suggests it has not tracked newer releases. The available information does not document a maintenance cadence, test suite, or license. Assume you would own long-term support internally if you vendored any of its code.
- What are the alternatives to this bundle for Laravel developers?
- The most direct alternative is the upstream intl-tel-input JavaScript package consumed through Vite, wrapped in a small Blade component you own. For validation, pair it with a PHP phone-number parsing library and a custom Laravel validation rule. That combination gives you the same flags, formatting, and country sync without Symfony Form coupling or an unmaintained dependency.
- What are the risks of adapting this Symfony bundle for Laravel?
- You would be porting Symfony form types, Twig templates, service wiring, and asset assumptions, which is usually more work than a thin Laravel-native implementation of the same widget. Additional risks include stale PHP and Symfony constraints, undocumented asset publishing, a bundled intl-tel-input and utils.js version you cannot easily upgrade, and mismatch between client-side formatting and server-side validation. Abandoned-package risk is also high given the near-zero community signals.
- Can I still read this bundle's source as a reference implementation?
- Yes, reading it is a reasonable way to see how someone wired intl-tel-input into a PHP form layer, provided you check the license on the GitLab repository first. Do not copy Symfony-specific form types or Twig themes into a Laravel app, since they will not fit. Extract only the ideas, such as hidden input handling and country sync, then implement them natively in Blade and Vite.