Product Decisions This Supports
- Content modeling: field vs. related stream. This package represents the "store a repeatable list in one column" option. It's the cheapest thing to ship for presentational data, and the most expensive thing to live with once someone asks to filter, sort, or report on individual items. That trade-off belongs in the design review, not in a sprint.
- Platform bet on Streams/PyroCMS/OpenClassify. Field-type coverage is a direct proxy for how much of your admin-configurable content model you get for free. If you're evaluating OpenClassify as a foundation, inventorying available field types (and their maintenance status) is a cheap way to size the build gap.
- Build vs. buy, honestly framed. This is a single-purpose addon: one field type that persists an ordered list of values. The real comparison is "adopt or fork this" versus "write the equivalent in one to two engineer-days." Cost is roughly a wash; the difference is ownership and future patching.
- Roadmap and ecosystem risk. One star, zero dependents, no release since May 2020. That's not a quality verdict on the code — it's an absence of any signal at all. It should feed a decision about whether to standardize new work on Streams or plan a quiet exit.
- Use cases it enables: admin-defined bullet lists, spec sheets, attribute lists, feature lists in a page builder — repeatable content that a content editor should own without a migration or an engineering ticket.
When to Consider This Package
Adopt only if most of the following hold:
- You are already running Streams/PyroCMS/OpenClassify; this is not a reason to start.
- The data is presentational and append-only in spirit: ordered lists of scalars rendered on the front end.
- No querying requirement. Nothing filters, sorts, aggregates, joins, or reports on individual list items — they arrive as a serialized blob.
- You are willing to vendor and fork it, pin the version, and carry the maintenance yourself. No upstream support, security patching, or compatibility guarantee exists.
- You have independently verified PHP 8.x and current Laravel compatibility — the 2020 release predates several breaking changes across both.
Look elsewhere if:
- You need item-level validation, permissions, localization, or workflow — that's a related stream, not a field.
- You need queryable data: use a normalized related stream, or a native JSON column with your database's JSON functions.
- You are not on Streams: use Filament's Repeater, Nova's KeyValue/Repeater fields, or a custom Eloquent cast. All are maintained and better documented.
- You need vendor support, SLAs, or an audited dependency — this fails procurement on every axis.
How to Pitch It (Stakeholders)
To executives: This is not a purchase decision and shouldn't appear on a roadmap as one. It's a small, unmaintained utility scoped to a single CMS ecosystem, with no adoption evidence behind it — one star, zero dependents, no release in five years. Recommendation: do not take it as a published dependency. If we're already committed to Streams, budget roughly one engineer-day to fork it and own it, or write the equivalent in-house. Same cost, better control, no orphaned third-party code in the stack.
To engineering: One field type that serializes an ordered list into a single column. Assume no upstream fixes and no compatibility guarantee with current Laravel and PHP. If we adopt it: vendor and pin it, move it under our namespace, add tests around serialization, empty states, and malformed-data handling, and document explicitly that the contents are not queryable — anything that needs to filter, sort, or report on list items gets normalized into its own stream from day one. Treat it as reference code that shows the pattern, not as a dependency we inherit.
Bottom line: Let it inform how we model repeatable content. Don't let it shape what we build next.