Country Field Type Laravel Package

Technical Evaluation

• Architecture fit: This is an Anomaly Labs / PyroCMS 3.x addon, not a general-purpose Laravel library. It plugs into the Streams Platform field-type registry so a stream field resolves to a country selector in the admin UI. There is no seam to attach it to a plain Laravel app — it is a CMS data-model component, not a reusable validation or reference-data service. Confirm the host application is actually on PyroCMS before evaluating further; otherwise the answer is "no fit."
• Integration feasibility: Requires a compatible anomaly/streams-platform version plus a country data source (bundled list, anomaly/geo, or a countries table). Composer constraints are likely pinned to the Laravel 5.x–8.x / PHP 7.x era, so resolution against a modern Laravel 10/11 app will likely fail or require a fork plus --ignore-platform-reqs. Install is via addon discovery and an addon:install migration, not a plain composer require.
• Technical risk:
  • Zero stars, zero dependents, no known consumers = no field-testing signal whatsoever.
  • Likely superseded: PyroCMS consolidated its addons into the pyrocms/pyrocms monorepo around 3.2+, so this standalone repo may already be stale or duplicated code that has drifted from the maintained version.
  • Opaque country source: whether the list is static JSON, a DB table, or a remote service decides air-gapped viability and data-refresh strategy.
  • Storage semantics risk: if the field persists display names rather than ISO 3166-1 alpha-2 codes, renames (Turkey→Türkiye, Swaziland→Eswatini) silently corrupt historical records and filters.
  • No visible CI/tests — framework bumps regress undetected.
• Key questions:
  1. Which PyroCMS/Streams version is targeted, and is the field type already bundled in the monorepo for that version?
  2. How are countries sourced, and what is the update path for ISO changes?
  3. What is persisted — code, name, or serialized object — and is it stable across renames?
  4. Does the dropdown respect application locale?
  5. Is there an active fork, and who owns security and framework-bump patches?
  6. Is a vendor fork acceptable under MIT, and where would it live?

Integration Approach

• Stack fit: Only fits a PyroCMS 3.x / Streams Platform application already using the addon model. Not a fit for plain Laravel, Livewire, Nova, Filament, or Inertia applications. If the org is not on PyroCMS, terminate the evaluation here.
• Migration path (PyroCMS only):
  1. Check whether the target PyroCMS version already ships a country field type in the monorepo — if so, drop this package entirely.
  2. Otherwise vendor the package into an internal monorepo via a path/VCS Composer repository rather than depending on abandoned Packagist upstream.
  3. Pin to a specific commit SHA and record it in the dependency ADR.
  4. Move country data into a first-class lookup (ISO 3166-1 table) so refreshes are a scheduled job, not a code change.
• Compatibility: Verify the PHP and Laravel constraints against the host app; expect a constraint bump plus typed-property/modernization cleanup. Verify the FieldType contract signature (getView(), getRules(), getOptions()) against the installed Streams major, since these have changed across versions.
• Sequencing:
  1. Spike (1–2 days) in a disposable PyroCMS instance: create a stream with the field, confirm the persisted format and admin rendering.
  2. Decision gate: use bundled version vs. vendor-fork vs. replace with a generic select fed by a country repository.
  3. If replacing: roughly one day of work, eliminates all upstream risk.
  4. Only then schedule rollout and normalization of any existing free-text country fields to ISO codes.

Operational Impact

• Maintenance: Effectively unmaintained upstream. Budget for internal ownership: Composer constraints, PHP/Laravel bumps, and ISO list refresh. Surface area is small (a field type, a view, a service class), so realistic cost is a few hours per platform upgrade — but it needs a named owner or it rots silently when the platform moves.
• Support: No vendor SLA. Community channels (PyroCMS chat, GitHub issues) are the only escalation path, and with zero stars a response is unlikely. An internal runbook must document where the fork lives, how to update the country list, and how to disable/roll back the addon.
• Scaling: Runtime cost is negligible — rendering a few hundred <option> entries in an admin select. Storage is one scalar per record with no query-path or index impact. If the UX needs searchable autocomplete later, that is a frontend change, not a data-scale problem. The real scaling risk is organizational: every additional PyroCMS instance multiplies fork-maintenance burden.
• Failure modes:
  • Composer resolution failure on framework upgrade — blocks deployments.
  • Country-data staleness — new or renamed countries missing; silent data-quality decay.
  • Name-based persistence — historical records show outdated values and filters break.
  • Namespace/addon registration drift after a platform upgrade — field renders blank or throws in the admin UI.
  • Locale fallback bugs — English-only dropdown in a non-English admin.
• Ramp-up: For a developer fluent in PyroCMS Streams addons, roughly half a day to read the field-type contract and country source. For a Laravel-only developer, 2–3 days, mostly learning the Streams addon lifecycle (service provider registration, field-type namespacing, admin view contract). TPM action: capture a one-page architecture note plus a "replace with select + ISO table" escape hatch so the team is never locked in.