Multiple Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is an anomaly/streams-platform addon (FieldType type) published under the visiosoft vendor namespace (the PyroCMS maintainers). It registers a multiple field type: a compound/repeater-style field that composes several sub-field types into one logical stream field, with the composed value persisted as a single serialized/JSON column. Fit is therefore close to binary:

• If the product runs PyroCMS 3.x or Streams Platform 1.x, this is native to the architecture — it slots into the existing field type registry, CP form builder, presenter, and schema builder with no bridging code.
• If the product runs vanilla Laravel, the package is unusable without adopting the entire Streams addon layer, which is a platform decision, not an integration decision.

The value it delivers is real but narrow: grouped, repeatable data in the control panel without designing custom Eloquent models/tables per shape.

Integration feasibility. Low effort inside Streams: composer require, service-provider registration via the addon manifest, streams:compile, and the field type appears in the admin picker. Practically zero feasibility outside Streams.

Technical risk. High, and driven by signal rather than code: 0 stars, 0 dependents, score 0.48. That pattern is consistent with either (a) an upstream mirror/fork of a package bundled transitively by PyroCMS, or (b) an effectively abandoned addon. Both imply no community backstop and a bus factor of roughly one. Specific risks:

• Storage as a text/JSON column means no per-subfield indexing or joins; filtering requires the addon's query modifier or post-filtering in PHP.
• Serialization format lock-in — schema-less payloads drift silently as sub-field definitions change.
• Validation is delegated to sub-field types; nested validation behavior must be verified, not assumed.
• Twig-based CP views are a compatibility surface that Streams major upgrades will move.

Key questions to answer before committing.

1. Is this a fork of anomaly/multiple-field-type, or the canonical source? Which one does PyroCMS 3.x actually resolve?
2. Is it already pulled in transitively by the PyroCMS meta-package? (0 dependents on Packagist suggests either transitive-only usage or none.)
3. What are the require constraints — PHP, laravel/framework, anomaly/streams-platform?
4. Does it ship a query modifier and schema builder, or storage-only?
5. JSON or PHP-serialized payload, and has that format ever changed across tags?
6. Is the Twig input view overridable per-project without forking?

Integration Approach

Stack fit. Confirm Laravel/PHP versions against the Streams version in use — PyroCMS 3.x pins differ by minor release, and this addon's constraint will be the binding one. Treat the Streams version, not the Laravel version, as the primary compatibility axis.

Migration path.

1. Discover, don't add. Establish whether the package is already present via PyroCMS's dependency tree. If so, you are already on the hook for it — document that and skip the direct dependency.
2. Introduce only if you have a concrete compound-field need; add via Composer, register/compile, and verify the field type appears in the admin picker.
3. Vendor fork into a private VCS repository immediately (MIT permits it). Pin to a tag, add a changelog of local patches, and require from the fork rather than Packagist.

Compatibility. The slug/namespace (multiple) is global within Streams — check for collisions if any other addon registers the same field type. Also verify the CP view paths resolve under your theme overrides.

Sequencing.

1. Spike: register the field type, confirm it renders in the CP.
2. Prototype one stream with a 2–3 subfield multiple field; exercise create/read/update/delete end to end.
3. Validate presenter/formatter output in Twig templates.
4. Validate querying and filtering — this is the most likely failure point; budget time here.
5. Only then design data migration: whether existing discrete columns collapse into a multiple field (lossy, one-way) or the new field coexists.
6. Fork + CI before the first production record is written.

Operational Impact

Maintenance. Assume you own it. With no upstream community, plan for roughly a few hours per quarter of proactive upkeep plus reactive work at each Streams major upgrade. The fork-with-changelog posture is not optional; it is the maintenance strategy.

Support. No docs beyond source, no issue traffic, no community. Onboarding cost is borne entirely internally — write a short internal README covering the payload shape and the field type's hooks (input view, presenter, modifier, query) so the knowledge is not single-person.

Scaling. Fine for low-cardinality repetition (2–10 groups per record). Degrades for high repeat counts, for reporting use cases, and for anything needing per-subfield aggregation — a JSON blob is invisible to SQL analytics. Watch row size and avoid putting large multiple fields on high-traffic list views where the presenter hydrates every row.

Failure modes to instrument.

• Streams upgrade breaks the view/presenter contract → CP form renders blank or silently drops the value on save.
• Payload format change across versions → older records unreadable or partially rendered.
• Sub-field renamed or removed → the field type writes only configured subfields; data loss is silent.
• Addon removed → column persists, nothing renders or validates it; orphaned data.
• Validation gaps → nested constraints not enforced, invalid payloads accepted at the API layer.
• Slug collision → duplicate field type registration, unpredictable resolution.

Ramp-up. 1–2 days for a developer already fluent in Streams addons; 1–2 weeks for a strong Laravel developer with no Streams exposure. Pair a Streams-experienced engineer on the first integration and require the prototype spike (steps 1–4 above) as the gate before committing to the dependency. Given the opportunity score of 6.59 against a risk profile this thin, the recommendation is: adopt only if already inside the PyroCMS dependency tree; otherwise prefer a purpose-built custom field or a plain related table.