State Field Type Laravel Package

Technical Evaluation

Architecture fit. anomaly/state-field_type is not a general-purpose Laravel package; it is an addon to the Anomaly Labs Streams Platform (PyroCMS 3.x). It registers a state field type that renders a dropdown of US states inside Streams field assignments. It fits only if the target application is already on PyroCMS/Streams. On a standard Laravel application, the package adds no value — an equivalent state select is a config array plus a Blade partial.

Integration feasibility. Technically simple: Composer install, service provider registration, field type available in the Streams admin UI, assign to a stream, render. The surface area is small. The real constraint is platform compatibility, not code complexity.

Technical risk.

• Zero stars, zero dependents, no community validation, no visible test suite. Treat as unmaintained sample code.
• Hardcoded US-state assumption; no internationalization or province/region support.
• Composer constraints may not resolve against modern PHP/Laravel; likely targets older Illuminate/Streams versions.
• MIT license permits vendoring/forking, which mitigates abandonment risk if we take ownership.
• Data-quality risk is higher than security risk: inconsistent state codes/names and weak validation.

Key questions.

1. Is the target application on PyroCMS 3.x / Streams, and at what version?
2. Do we need US-only states or international regions?
3. Does the field store state code, name, or both — and what is the backfill mapping?
4. Can Composer resolve it against our PHP and platform constraints without conflict?
5. Who owns the fork, tests, and state list updates?
6. Does it support nullable, required, default, and validation rules in Streams?

Integration Approach

Stack fit. Only viable for PyroCMS/Streams stacks. For standard Laravel, do not adopt — implement a config-driven state select locally (roughly one config file, one form request rule, one Blade component). For Streams, adopt only as a small, vendored addon.

Migration path. If already on Streams: install, register the field type, assign it to the relevant stream, migrate existing address data, and verify stored values. If replacing a hardcoded select, map legacy values to the new option values and backfill before cutover. If not on Streams, there is no migration path worth pursuing.

Compatibility. Pin the package to the platform version and test Composer resolution on the target PHP runtime. Because there are no dependents, assume it has not been exercised against current Laravel/Streams releases. Run a staging spike before committing to production use. Check composer.json constraints for illuminate/*, php, and anomaly/streams-platform.

Sequencing.

1. Confirm PyroCMS/Streams version and whether the field type is actually needed.
2. Spike install in a disposable environment; verify registration and rendering.
3. Decide: consume upstream, fork, or reimplement locally.
4. If forked, add tests, CI, and a documented state list.
5. Define field on a staging stream and validate validation/required behavior.
6. Backfill and reconcile existing data.
7. Roll out and document ownership.

Operational Impact

Maintenance. Low code volume but effectively no upstream maintenance. Budget for an internal fork and periodic review against PHP and PyroCMS upgrades. The state list itself is a minor ongoing data-maintenance item.

Support. No vendor support and no community. Internal ownership is mandatory. Document the field type, storage format, and validation behavior so it is not opaque to future developers.

Scaling. Negligible runtime impact — a static dropdown backed by a string column. Not a scaling concern. Database column type and indexing matter more than the field type.

Failure modes.

• Composer conflict or boot failure after a platform/PHP upgrade.
• Field type not registered or missing language keys, causing admin UI errors.
• Hardcoded US states producing invalid options for non-US users.
• Validation bypass or inconsistent stored values (code vs. name).
• Silent breakage from lack of tests.

Ramp-up. Minimal for a developer already familiar with PyroCMS/Streams (hours). For a Laravel-only team, the Streams field-type model adds a learning curve (1–2 days), but cloning the functionality locally is trivial. Overall: a low-value, low-risk convenience addon — adopt only inside an existing Streams estate, and only with a fork-and-own plan.