Intl Tel Input Bundle Laravel Package

Product Decisions This Supports

• International phone capture as a first-class form capability. If any roadmap item depends on collecting phone numbers from users outside a single home market — signup, checkout, KYC/onboarding, delivery contact, SMS OTP or 2FA enrollment, lead-gen forms — this package represents one (narrow) implementation of that capability. The decision it informs is "standardize phone input or keep bolting regexes onto each form."
• Build vs. buy vs. adopt-the-underlying-library. The package is a thin Symfony 4 form-type wrapper around the mature intl-tel-input JavaScript library. The real product decision is not "this bundle or nothing" — it's "do we standardize on the underlying JS widget plus a server-side validator, or build formatting/validation ourselves?" This package is useful primarily as a reference design for that decision, not as a dependency.
• Stack-fit triage. The most important product fact is a mismatch: this is a Symfony 4 bundle, not a Laravel package. For a Laravel codebase it is not installable in any meaningful sense. That reframes the assessment from "adopt or not" to "ignore as a dependency, mine as prior art." The underlying widget is framework-agnostic; the wrapper is not.
• Roadmap inputs for compliance-adjacent flows. Phone capture touches SMS consent language (region-dependent), E.164 normalization for downstream messaging vendors, and data-handling review. Deciding where phone numbers are validated (client-side UX only vs. authoritative server-side) is a product/risk call this evaluation surfaces.
• Prioritization signal on form UX debt. If multiple teams have independently hand-rolled country dropdowns and permissive phone regexes, that's evidence of a shared-component gap worth a small platform investment.

When to Consider This Package

Consider it only under a narrow set of conditions:

• You are running an existing Symfony 4 application with form-heavy admin or onboarding flows and need a country selector plus display formatting quickly.
• You accept that Symfony 4 is end-of-life for security support, and that you will likely need to fork and patch the bundle yourself.
• You need only client-side presentation and formatting, with validation handled elsewhere.

Look elsewhere — and by default, do not adopt — when:

• You are on Laravel. Use the intl-tel-input JS asset directly plus a Laravel validation rule; the bundle's form-type integration does not port.
• You need server-side truth. Never trust client-side phone validation. Pair any widget with a real library (giggsey/libphonenumber-for-php) for E.164 normalization and carrier/region checks.
• You need maintained dependencies. Zero stars, zero dependents, a single maintainer, no visible CI or security policy is a weak maintenance signal. Composer dependencies are transitive trust; an unmaintained wrapper is a future forced migration.
• You are on modern PHP/Symfony (6/7) or PHP 8.2+. Compatibility is unproven and unlikely.
• You have design-system or accessibility requirements. Phone inputs need labeled country comboboxes, keyboard navigation, and screen-reader behavior. A thin wrapper rarely satisfies an internal design system.
• You need current libphonenumber metadata (new numbering plans, region changes). Bundled metadata ages quickly; verify the update path.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small, unmaintained Symfony 4 wrapper around a well-known open-source phone-input widget. It has effectively no adoption, no dependents, and a single maintainer, and it does not fit our Laravel stack. Recommendation: do not add it as a dependency. If international phone capture is on the roadmap, we can deliver it in roughly one to two engineering days by integrating the underlying open-source widget and a reputable server-side phone-number library — both actively maintained, both MIT-licensed. The cost of adopting this bundle instead is not the install; it's the indefinite maintenance and security-review burden of owning an abandoned wrapper on an end-of-life framework.

To engineering: Treat this as prior art, not a candidate. Copy the integration pattern — client-side formatting for UX, authoritative server-side parsing/validation into E.164, store normalized values, and keep the raw input for support/debugging. Budget for metadata refresh (numbering plans change) and for accessibility work on the country selector, which wrappers typically skip. Flag the supply-chain point explicitly: a 0-star, 0-dependent, single-maintainer package on EOL Symfony is a poor risk trade for a component we can own in a day.

What would change the recommendation: signs of active maintenance (recent commits, CI, Symfony 6/7 and PHP 8.2+ support, issue activity), demonstrated adoption, or a documented security and metadata-update process. Absent those, the right call is to build the thin layer ourselves on top of maintained foundations.