Country Field Type Laravel Package

Product Decisions This Supports

• Adding country/region capture to content and forms — this package registers a country field type with the Anomaly Streams Platform (PyroCMS), so product teams can add a country selector to any Streams-based content type (company profiles, event locations, store/office directories, lead forms, member records) without building a custom field, validation layer, or country list.
• Build vs. buy for small, undifferentiated UI — a country picker is commodity functionality. This package makes the "buy" (adopt) case a same-day decision instead of a one-to-two sprint build, which matters more for the shape of the roadmap than the actual work saved.
• Geographic expansion work — the first concrete step in any "launch in market X" roadmap is usually letting content and users express where they are. A consistent country field enables market segmentation, localized catalogs, regional navigation, and jurisdiction-aware content rules.
• Compliance and reporting scope — country is a common proxy for tax jurisdiction, shipping eligibility, data-residency, and VAT/GDPR-adjacent reporting. Committing to a field-level representation now determines how much cleanup downstream analytics and finance work will need.
• Localization and editorial targeting — supports content targeting by market, region-filtered listings, and country-specific landing pages, which are typically the cheapest wins in an internationalization roadmap.
• Use cases to prioritize against: address capture, distributor/partner directories, shipping-zone config, event and job listings, lead routing by territory, and customer segmentation for pricing.

When to Consider This Package

Consider it when:

• You are already running PyroCMS or the Anomaly Streams Platform. Outside that ecosystem this package does essentially nothing — it is an addon, not a standalone Laravel validation or country-data library.
• You need a country selector inside Streams admin forms and field assignments, and want the country list, form UI, and storage handled consistently rather than hand-rolled per content type.
• You want the field to behave like every other Streams field (assignment, migration, entry rendering) so non-engineers can add countries to content types themselves.
• You need only country-level granularity — one field, one selection, no dependent sub-regions.

Look elsewhere when:

• You are not on Streams/PyroCMS. Use a maintained country-data package (e.g. ISO-3166 datasets, league/iso3166, rinvex/country) plus your admin framework's select field (Filament, Nova, Backpack, plain Blade).
• You need more than a picker: states/provinces/cities with dependent dropdowns, postal-code and address validation, geo-IP detection, phone formatting, country names translated at render time, or flags/locale display. This field type is not an address or geo platform.
• Maintenance risk is unacceptable. Zero stars, zero dependents, and a low opportunity score are strong signals of a single-maintainer or dormant addon. Treat it as vendored code: pin the version, review the country dataset for staleness (renamed/recognized countries change), confirm how the ISO code is stored and validated, and be prepared to fork. Do not put it on a path where a security patch or a Laravel major upgrade is someone else's problem.
• You need a canonical, auditable country dataset for compliance or finance reporting — source and version the data explicitly rather than inheriting it from a field type.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed addon that gives our CMS a country selector out of the box. It removes a minor but recurring build task from every feature that needs to know "where" — market pages, directories, lead routing, regional content — and it costs nothing to license. The honest caveat is adoption signal: no stars, no dependent projects, one maintainer. So we should treat it as a tactical convenience, not a strategic dependency: adopt it where we're already on the Streams platform, pin the version, and budget a day to fork it if it goes quiet. It does not change our platform strategy; it just avoids us rebuilding a dropdown five times.

For engineering: It's a Streams field type — registers a country field, supplies the option list and the admin input, stores a country value against the entry. No external services, no runtime dependency, minimal attack surface. Before adopting, verify three things: (1) the storage format and whether it's an ISO 3166-1 alpha-2 code we can join on in analytics, (2) how stale the embedded country list is and whether we can override it, (3) compatibility with our current Streams/Laravel versions. If any of those are awkward, the fallback is trivial — a select field backed by a maintained ISO dataset — so the downside is bounded to roughly a day of work either way.

Recommendation: Approve as a low-risk, in-ecosystem convenience; gate adoption on the three checks above and record it as vendored rather than as a dependency we expect upstream support for.