Multiple Field Type Laravel Package

Technical Evaluation

Architecture fit

This is not a general-purpose Laravel package. It is a PyroCMS Streams Platform field-type addon — an extension that plugs into the Anomaly streams-platform addon architecture rather than into Laravel's service container directly. Its integration points are addon-specific:

• A service provider extending the platform's FieldTypeServiceProvider, with addon metadata (manifest.json/addon.php), a custom Composer type, and autodiscovery driven by the Streams addon loader — not standard Laravel package discovery.
• A field type class extending the platform FieldType base, a presenter for render/serialization, and a migration column stub.
• Config, language, and view assets under resources/config, resources/lang, resources/views using the platform's namespaced asset conventions.

Consequence: architecture fit is effectively all-or-nothing. If the target application is PyroCMS 3.x with the Streams Platform installed, this is a native, idiomatic component. If it is any other Laravel application — including a bespoke app using Eloquent casts, Nova, Filament, or Livewire — it provides no reusable value. There is no extractable "multi-value field" abstraction here that survives decoupling from Streams.

Integration feasibility

Low standalone feasibility, moderate feasibility inside a PyroCMS estate.

The blocker is not code quality — it is the version envelope. PyroCMS's Streams Platform stagnated in the Laravel 5.x era; modern Laravel (10/11/12) requires PHP 8.1+, typed properties, and a completely reworked package discovery contract. Grafting this addon onto a current Laravel app is not an integration task, it is a rewrite of the host platform.

Technical risk

• Abandonment risk: high. Zero stars, zero dependents, no downstream validation. There is no signal that this addon is exercised in production by anyone but its author.
• Compatibility risk: high. A composer require will almost certainly conflict on laravel/framework, illuminate/*, and anomaly/streams-platform constraints in any modern project.
• Data-shape risk: medium. Multi-value field types in this ecosystem typically persist to a text column as delimited or serialized data. That is a denormalized design — no indexing, no referential integrity, and no queryable structure. Migrating away later requires a data migration, not just a dependency swap.
• Blast radius: low. With zero dependents and a narrow host requirement, a failure here cannot cascade. This is the one favorable property.
• Security surface: low. Small, UI-layer addon; limited attack surface, though also unaudited.

Key questions

1. What does the addon's composer.json actually pin for php, laravel/framework, and anomaly/streams-platform? This single file determines go/no-go.
2. Is the host application already a PyroCMS 3.x deployment, or are we attempting to introduce this into a non-PyroCMS Laravel app? If the latter, the evaluation ends here.
3. Does "multiple" mean multi-select from a fixed option set, multiple related stream entries, or a repeatable composite of another field type? These have materially different storage and query implications.
4. How are values persisted — delimited string, JSON, or a pivot/assignment table? Determines whether the data is portable.
5. Is there a maintained fork or a Streams Platform successor that supersedes this addon?
6. Who is the accountable owner if upstream goes dark? (Assume it already has.)

Integration Approach

Stack fit

The stack fit is narrow but clean: PyroCMS 3.x + Streams Platform + PHP 7.x. Within that envelope, the addon is a first-class citizen — it inherits the platform's form builder, validation pipeline, translations, and control-panel rendering for free. Outside that envelope, fit is zero. There is no adapter layer worth writing.

Practical guidance: treat this as a configuration decision inside an existing PyroCMS estate, never as a component selection for a greenfield Laravel build.

Migration path

Two directions to consider:

Adopting it (inside PyroCMS):

1. Pin the addon to an exact tag (do not float on dev-master; there is no release cadence to rely on).
2. Vendor the source into the repository — fork it under the org namespace — rather than depending on Packagist. With zero dependents and no maintenance signal, an upstream deletion or force-push is a realistic failure mode.
3. Register the addon, assign the field type to a stream, and run the platform's field migration.
4. Validate round-trip: create → persist → re-render → edit → serialization of empty and multi-value cases.

Migrating away (recommended long-term):

1. Inventory which streams use this field type and how many rows carry data.
2. Read the persisted format and write a one-off normalizer into a portable shape — ideally a JSON column with an Eloquent array/json cast, or a proper pivot table if the values are entity references.
3. Only then remove the addon. Do not remove the addon before the data migration; the render layer is the only thing that knows the storage encoding.

Compatibility

• Assume Laravel 5.4–5.8 and PHP 7.1/7.2. Confirm, do not assume — an old addon may pin even tighter via a streams-platform transitive constraint.
• If the host is on Laravel 9+, expect a hard Composer resolution failure. Do not attempt to force-resolve with --ignore-platform-reqs; the runtime break will be in the addon loader, not in Composer.
• Check whether the addon depends on laravelcollective/html form macros. That package is itself abandoned and is a second, independent blocker on modern Laravel.

Sequencing

1. Confirm host is PyroCMS and capture the exact platform version. (gate)
2. Read composer.json and resolve the PHP/Laravel constraint envelope. (gate)
3. Decide build-vs-adopt: if any modernization is on the roadmap, skip adoption entirely and build a JSON-cast-backed equivalent, which is a few hours of work and has no platform lockdown.
4. If adopting: fork → vendor → pin → integrate on a single low-traffic stream → validate round-trip.
5. If the field proves useful, schedule the portability work (JSON/pivot) now, while the dataset is small, not at decommission time.

Operational Impact

Maintenance

Effectively unmaintained. Zero stars and zero dependents is not a popularity signal to discount — in the PyroCMS addon ecosystem it is a direct proxy for "no one is filing issues, so no one is fixing them." Budget for the addon being org-owned code from day one: fork, vendor, and assign an internal owner. Any upgrade of the host platform becomes an upgrade of this addon too, with no upstream to lean on.

Support

No community, no issue triage, no security advisories. Internal support only. The realistic support path is "read the source," which is tractable — the surface is small (a field type class, a presenter, a view, config, and migrations) — but it requires someone fluent in the Streams Platform addon contract, which is a thin skill pool in 2024+.

Scaling

Adequate at small scale, degrading with data volume:

• Delimited/serialized storage means no index-backed filtering or sorting on the field's values. Queries become LIKE '%value%' scans.
• Eager-loading and pagination on streams that filter by this field will not benefit from indexes.
• At low thousands of rows this is invisible; at hundreds of thousands it becomes a query-plan problem that requires a schema change — i.e., a migration off the field type under production load.

Recommendation: cap usage to low-cardinality, low-row-count streams, and avoid it on any stream expected to grow past ~10^4 rows or to be filtered in list views.

Failure modes

Ramp-up

• Platform-fluent developer: ~half a day to read the addon, register it, and validate a stream. Low ceremony.
• General Laravel developer without Streams experience: 2–3 days, most of it spent learning the addon contract and control-panel conventions rather than this package specifically.
• Ongoing bus factor: 1. The realistic number of people who understand both this addon and the surrounding Streams Platform inside a typical team is one, and if the team has no PyroCMS history, it is zero.

Bottom line for the roadmap: the 0.48 score is fair. This is a competent, idiomatic component for a platform generation that has passed. Adopt only if the host is already a pinned PyroCMS 3.x estate with no modernization on the horizon — and even then, fork and vendor it. Otherwise, the correct call is to implement the equivalent as a JSON-cast column plus a native admin control: a small, bounded piece of work with no platform lockdown, no abandoned transitive dependencies, and queryable data.