State Field Type Laravel Package

Product Decisions This Supports

• Feature scoping for address capture. A "state" field is a small but load-bearing input in checkout, billing/shipping, onboarding, KYC, and tax-nexus flows. This package answers the recurring build-vs-buy question for that input: reuse a Streams Platform field type instead of hand-rolling a select in every form.
• Build vs. buy. Writing a US-state dropdown is trivial (a config array plus a <select>); the package's actual value is convention — consistent labels, codes, ordering, and validation behavior across every admin/CRUD screen in a PyroCMS/Streams codebase. That is a consistency decision, not a capability decision.
• Consistency and data integrity. State codes are an enum that leaks into tax rules, shipping zones, and reporting. A shared field type reduces per-form divergence (e.g., "California" vs. "CA" vs. "Calif.") that later breaks joins and eligibility checks.
• Roadmap / ecosystem bet. Adopting it is a soft vote for the anomaly/* field-type family and the Streams Platform's addon model. Low individual cost, but it accumulates into platform lock-in and constrains a future migration to plain Laravel + Livewire/Inertia or Filament.
• Risk triage, not capability evaluation. With 0 stars, 0 dependents, and a low health score, the honest PM framing is "tiny, MIT-licensed, effectively unmaintained commodity code." Treat it as vendorable source, not a maintained dependency — which is fine for a config array and unacceptable for anything with active upstream needs.

When to Consider This Package

Adopt when all of these hold:

• You are already running PyroCMS / the Streams Platform and building forms through its field-type system (outside that context this package has essentially no value — it is an addon, not a standalone library).
• Your requirement is US-only state selection as a plain dropdown, with no dependent logic.
• You are comfortable vendoring or forking ~trivial code, since upstream maintenance signals are effectively absent.
• The alternative is duplicated, inconsistent selects scattered across multiple modules.

Look elsewhere when:

• You need international subdivisions (Canadian provinces, EU regions, AU states) — use commerceguys/addressing, Symfony Intl, or a maintained region dataset instead.
• You need address-level correctness: ZIP↔state consistency, tax-nexus rules, shipping-zone resolution. That is a domain/validation problem a dropdown does not solve.
• You need UX beyond a plain select — searchable, typeahead, autocomplete, or strong accessibility guarantees.
• Your team's roadmap points away from the Streams Platform; adopting addons deepens a migration you may already be planning.
• You require a dependency with active maintenance, security response, or a support contract.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) component that standardizes how we capture US state information across our forms, avoiding duplicated work and inconsistent data that later complicates tax and shipping logic. Cost of adoption is hours, not weeks. The risk is equally small and fully contained: the code is simple enough that we can own a copy outright if the maintainer disappears, so we are not exposed to a vendor failure.

To engineering: This is an anomaly/* field type for the Streams Platform — a config-driven US state dropdown, MIT-licensed, with negligible adoption (0 stars, 0 dependents). Recommendation: use it only if we are already on Streams and want consistency across admin forms; otherwise copy the state list into our own form component and skip the dependency. Do not build tax, shipping, or address-validation logic on top of it.

Bottom line: a low-stakes consistency play inside a specific ecosystem — buy (or rather, borrow) only if you are already there, and keep the fork rights in your back pocket.