Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Select Country Code Laravel Package

tapp/select-country-code

A Laravel package for adding a country code selector to forms. It ships country and dial code data with a ready-to-use select component, making it easy to build searchable phone-number inputs in Blade views and Livewire components. Lightweight and simple to drop into any Laravel project.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Tactical build-vs-configure, not build-vs-buy. This is not a platform decision — it's a ~30-line Nova field configuration. The real decision it informs is "do we take a third-party dependency for a commodity admin form control, or configure Nova's native Select with a country dataset?"
  • Country as a data-model decision. Any feature requiring a country field (customer profiles, shipping/billing addresses, tax and VAT rules, shipping zones, regional pricing, market expansion, geo-routing) forces a choice the package doesn't make for you: store ISO 3166-1 alpha-2 vs alpha-3 vs numeric, display code vs localized name, and whether you'll later need subdivisions, dial codes, or currency mapping. Decide this once, centrally.
  • Feature scoping honesty. "Add country to the customer record" is a small ticket, not an initiative. Treating this package as a strategic dependency would inflate a routine admin change into an adoption review.
  • Dependency-risk posture. 5 stars, zero dependents, and a last release of 2021-03-26 is a red flag specifically because Laravel Nova has shipped multiple majors since. A field package is tightly coupled to Nova's internals, so "unmaintained" here translates directly to "blocks your Nova upgrade."
  • Roadmap signal for internationalization. If country becomes first-class (localized country names, per-market catalogs, compliance-driven address formats), the right move is a maintained data layer (league/iso3166, symfony/intl, commerceguys/addressing) with a thin Nova field on top — not a UI widget package.
  • Opportunity score of 21.3 is directionally correct. Low strategic leverage, low adoption, high staleness. It supports a "don't standardize on this" conclusion more than a "adopt this" one.

When to Consider This Package

Consider it only when all of the following hold:

  • You are on the Nova major this was built against (likely Nova 2/3-era) and have verified it renders and validates correctly in your version.
  • The field is already in your codebase and the cost of ripping it out exceeds the cost of leaving it — i.e., a maintenance decision, not a greenfield one.
  • You need a deliberately minimal dropdown and a plain list of country codes is genuinely sufficient for your admin users.
  • The field's behavior is meaningfully better than Nova's native Select (e.g., it provides search/typeahead, flag rendering, or code-to-name labeling you'd otherwise build).

Look elsewhere — usually at Nova's built-in Select plus a maintained dataset — when:

  • You're on Nova 4/5 or planning an upgrade; a 2021 field is a likely breakage point.
  • You need searchable selection at ~250 options (country lists are unpleasantly long in a plain select), flags, or localized country names.
  • You need anything beyond ISO codes — dial codes, subdivisions/states, address formatting, VAT validation. These are data problems, not field problems.
  • You require an actively maintained dependency, a security/supply-chain review, or vendor responsiveness for support.
  • You need validation guarantees (ISO membership, alpha-2 enforcement) — that belongs in a form request or model cast, not implicitly in a UI widget.

How to Pitch It (Stakeholders)

To executives: This package is a small, free UI convenience for the Nova admin panel with effectively no adoption (5 stars, 0 dependents) and no release since March 2021, while Nova itself has moved through several major versions. It has near-zero strategic value and carries a real, if modest, upgrade-and-abandonment risk. Recommendation: do not adopt it for new work. If it already exists in our codebase, keep it only until the next Nova upgrade and replace it with Nova's native select field backed by a maintained country dataset — a small, bounded piece of work.

To engineering: Prefer Nova's built-in Select populated from a maintained source (league/iso3166 or a checked-in ISO list), with validation in a form request and a model-level cast/enum for the stored code. That's roughly 30 lines, removes a stale third-party dependency, survives Nova upgrades, and gives us control over display names and searchability. If we keep the existing package, pin it, and add the swap to the Nova upgrade checklist. Either way, resolve the storage format (alpha-2 recommended) now so downstream features — tax, shipping zones, localization — aren't blocked by a UI-level choice.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core