Phone Number Bundle Laravel Package

Product Decisions This Supports

Feature bets this informs. Any surface where a user types, imports, or receives a phone number: signup/onboarding with phone verification, SMS OTP and 2FA, international checkout with contact capture, CRM/contact imports, notification routing (SMS vs. voice vs. push fallback), and fraud/abuse screening. The capability underneath is always the same three primitives — parse, validate, normalize to E.164 — plus locale-aware display formatting and line-type detection (mobile / fixed / VoIP).

Roadmap: market expansion. Phone validation is a gating dependency for launching in new countries. If we can't validate and normalize a Brazilian or Indian number, we can't onboard those users or price SMS correctly. The metadata coverage of libphonenumber, not the wrapper, is what determines which markets are addressable.

Build vs. buy. The real decision is "adopt libphonenumber vs. hand-roll." Hand-rolling prefix/carrier rules is indefensible — the rules change constantly and Google maintains the canonical dataset. But this package is only a thin Symfony DI/config wrapper over that dataset. The build cost to replicate the wrapper is roughly a day; the buy value is concentrated entirely in the dependency, not the wrapper.

Direct cost lever. Validating before dispatch avoids paying an SMS provider for numbers that were never deliverable. That gives a measurable, per-market ROI number for what is otherwise a "hygiene" ticket — useful for prioritization.

Concrete use cases to cite in a spec: normalize to E.164 before persistence; reject invalid input at the edge rather than at send time; format for display per user locale; extract a number from pasted free text; route OTP over SMS only for mobile line types; block known VoIP/virtual ranges on high-risk flows.

When to Consider This Package

Consider it only if:

• You are running a Symfony 2/3/4 application, this bundle is already installed, and the question is maintenance rather than greenfield adoption.
• You specifically want the pre-wired service, validator constraint, and template helper, and would otherwise write that wiring yourself.
• Your organization has accepted the long-term maintenance burden of an unmaintained dependency as a deliberate trade to avoid touching a legacy app.

Look elsewhere if:

• You are on Laravel. The package is a Symfony bundle, not a Laravel package — it will not integrate. Use propaganistas/laravel-phone, or bind giggsey/libphonenumber-for-php behind your own service in a provider.
• You are on Symfony 5, 6, or 7. This bundle advertises Symfony 2–4 only. Use odolbeau/phone-number-bundle or the underlying library directly.
• You require a maintained dependency. Last release was 2020-11-03, with 0 stars, 0 dependents, and a 0 score. There is no community, no visible CI, no security-response path, and no framework-version currency. That is a supply-chain and onboarding cost with no offsetting benefit.
• You need to go beyond thin wrapping — custom metadata, caching strategy, regional format overrides, or async/bulk validation. You will end up forking it, at which point you own it without having chosen to.

What would change the verdict: a maintained fork, Symfony 6/7 support, a release within the last 12 months, CI with tests, and at least one real dependent. None of those hold today.

Flag before proceeding: the package is described upstream as a Symfony bundle. If this evaluation was requested as a Laravel integration, the premise is wrong and the correct candidate is propaganistas/laravel-phone — worth confirming before any further work.

How to Pitch It (Stakeholders)

For executives. Phone handling is a data-quality and cost-control problem, not a UI nicety. The capability we need — turning messy international input into one canonical format, validating numbers before we pay a messaging provider, and displaying them correctly per market — comes from libphonenumber, Google's industry-standard dataset. This package is a small adapter around that library for an older Symfony version: last released in 2020, no adoption, no maintenance signal, and not built for our stack. Recommendation: adopt the underlying library (or a maintained framework adapter), not this package. The engineering cost either way is on the order of a day; the actual risk is inheriting an abandoned wrapper and discovering it during a market launch.

For engineering. Treat the wrapper as replaceable, not strategic. Consume giggsey/libphonenumber-for-php behind our own PhoneNumber interface with four methods — parse, validate, format, lineType — so a future adapter swap is a one-file change. The genuine ongoing cost is metadata currency: pin the library, subscribe to its release cadence, and decide now whether metadata updates ride the normal dependency-upgrade train or need a scheduled job. That cost exists regardless of which wrapper we pick, so it should be the deciding factor rather than the wrapper's ergonomics.

For product. Budget one day of engineering for the integration plus a small recurring allowance for metadata updates. If the wrapper is used at all, use it on legacy Symfony surfaces only and record it as technical debt with an owner and a replacement trigger.