Video Field Type Laravel Package

Technical Evaluation

Architecture fit. anomaly/video-field_type is not a general-purpose Laravel package — it is an addon for the Streams Platform (PyroCMS 3.x), written by Anomaly Labs. Its entire value proposition is registering a new field type inside Streams' field-type registry so that content types can declare a video field. It hooks into Streams' FieldType contract, its asset/control-panel conventions, and the addon bootstrapping lifecycle. For a codebase already on PyroCMS 3, this is an idiomatic fit; for any other Laravel application (Nova, Filament, plain Blade, Livewire, Inertia), the architecture does not apply. There is no portable service class you can lift out — the semantics are defined by Streams.

Integration feasibility. Trivial if and only if the host is PyroCMS 3 / Streams. composer require anomaly/video-field_type, then enable the addon and the field type becomes selectable when defining a stream field. The field appears to store a reference/identifier (provider + video ID, or a file reference) rather than raw binary, which keeps the schema light. Outside that environment, integration effort is effectively "fork and rewrite," which is not a reasonable TPM recommendation.

Technical risk. High, driven almost entirely by ecosystem health rather than code quality:

• 0 stars, 0 dependents, score 0.27 — no observable community validation, no downstream users to surface regressions, no external issue traffic.
• Maintenance signal is weak. Anomaly Labs' public activity around PyroCMS/Streams has slowed considerably; the repo is likely in maintenance-only or abandoned status. Assume no upstream fixes.
• Version coupling. Field types are tightly bound to Streams major versions and to the PHP/Laravel matrix PyroCMS 3 supports (historically PHP 7.x-era, Laravel 5.x/6.x). Running this on PHP 8.2+/Laravel 10+ is unlikely without patching.
• Hidden dependency surface. Video field types typically rely on a provider/plugin layer (e.g., YouTube/Vimeo metadata, possibly anomaly/files-module for uploads). Those transitive addons must be compatible too.
• MIT license is permissive and low-risk from a legal standpoint — you can vendor/fork if needed.

Key questions before committing.

1. Which PyroCMS/Streams version does this target, and which PHP/Laravel versions does its composer.json permit?
2. Is it a reference field (stores provider + ID, resolution at render) or does it upload video? That determines storage and CDN implications.
3. Which provider integrations are baked in, and do they call live APIs (rate limits, API key handling, breaking changes)?
4. Who owns the fork if upstream is dead — is there appetite to vendor and patch?
5. Do existing content types already store video as URL/string fields that would need migration?

Integration Approach

Stack fit. Only PyroCMS 3.x with the Streams Platform. If the target stack is Laravel + Nova, Filament, or a custom admin, do not adopt this package; instead model video as a JSON column ({provider, id, url, thumbnail}) plus a form component, or use a maintained media library (Spatie Media Library, Plank, etc.). The TPM recommendation should state this plainly — the package is not stack-agnostic.

Migration path. For a PyroCMS host:

1. Pin the addon to a commit/tag in composer.json (no floating dev-master), commit the lockfile.
2. Install into a staging environment and verify the field type registers in the CP.
3. Create a throwaway stream with a video field; exercise create/edit/render/delete.
4. Backfill existing content: if legacy fields are URLs or embedded HTML, write an assignment migration that parses provider + ID into the new field's storage shape.
5. Roll out to a single content type, then expand.

Compatibility. Validate against the exact Streams version in the host. Because dependents are zero, you cannot rely on anyone else's compatibility testing — treat the host's own test suite plus manual CP checks as the gate. Expect to patch composer.json constraints for newer PHP.

Sequencing. (a) Prove the field type on a scratch stream → (b) validate rendering across all front-end templates that will consume it → (c) migrate one content type → (d) migrate the rest → (e) document the fork/ownership plan. Do not sequence this ahead of confirming PyroCMS/Streams version alignment; that is the go/no-go gate.

Operational Impact

Maintenance. Effectively self-maintained. With no stars, no dependents, and a quiet upstream, budget for owning a fork: security patches for transitive dependencies, PHP/Laravel constraint bumps, and provider API drift (YouTube/Vimeo embed and metadata endpoints change). This is a recurring cost on the roadmap, not a one-time install.

Support. None beyond public issues, and likely no responses. Internal documentation and a named owner are mandatory. If the host team lacks PyroCMS depth, this becomes a bus-factor risk.

Scaling. Storage scaling is modest if the field stores references (provider ID + thumbnail URL) — cost is negligible. If it uploads, video storage/egress dominates and should be offloaded to object storage + CDN regardless of the field type. Rendering fan-out is cheap; provider API calls at render time are not — cache metadata and thumbnails locally.

Failure modes.

• Provider video removed/private → broken embeds; needs graceful fallback UI.
• Provider API breaking change or key expiry → field save/render failures.
• Streams upgrade invalidates the field type registration → content types render blank; caught only by staging tests.
• Missing transitive addon (files module, video plugin) → install succeeds but field type fails at runtime.
• Fork drift → lockfile conflicts and silent regressions on composer update.

Ramp-up. Low for a developer already fluent in PyroCMS/Streams addon conventions (hours). Moderate-to-high for a general Laravel team unfamiliar with Streams — the field-type contract, CP asset pipeline, and addon lifecycle are non-obvious and undocumented here. Plan a spike before committing the team to this dependency.

TPM verdict. Low-risk license, high ecosystem risk. Adopt only inside an existing PyroCMS 3 deployment with a named internal owner and a fork plan; reject for any greenfield or non-Pyro Laravel stack, where a small custom field or a maintained media library is the lower-total-cost choice.