Singlefile Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a Streams Platform addon (PyroCMS lineage) that registers a field type with the Anomaly\Streams\Platform\Addon\FieldType\FieldType base class and an admin input view rendered through Twig. It only has meaning inside an application bootstrapped with anomaly/streams-platform, where field types are discovered by the addon registry and bound to assignment columns in generated entry tables. In a vanilla Laravel app there is no seam to attach it to; the "integration" would effectively be adopting PyroCMS.

Integration feasibility. Feasible only for teams already running a Streams-based stack — most plausibly OpenClassify or a PyroCMS 3 site, given the openclassify org namespace and the visiosoft vendor prefix. Adoption is a composer require plus addon discovery, but the practical gate is version alignment: this package's release history ends in Feb 2022, which places it in the Laravel 5.x / PHP 7.x era. Any host application on Laravel 9+, PHP 8.1+, or with modern Composer 2.3+ audit policies should assume it will not resolve cleanly.

Technical risk. High, and concentrated in four areas:

• Maintenance risk: zero stars, zero dependents, single-vendor ownership, no release in 3+ years, no visible CI or test suite. There is no upstream to inherit fixes from.
• Blast radius: field types sit on the write path for every entry save. A defect in setValue()/getPostValue() corrupts or drops references silently, and Streams has no built-in referential integrity between a path string and the file on disk.
• Upload security: the value of the package hinges on whether it enforces MIME/extension allowlists, size caps, filename sanitization, and storage-disk scoping. With no maintained release, any gap becomes yours to patch.
• Duplication: Streams already ships anomaly/files-field_type backed by the Files module (metadata, thumbnails, cleanup on delete). This addon appears to be a lighter single-file variant; confirm it is not simply bypassing that module and re-implementing storage, which would mean orphaned files and no media abstraction.

Key questions.

1. What exactly is persisted — a relative path, a disk-qualified path, or a Files-module ID? This determines whether existing data can be migrated and whether deletion cascades.
2. Does it use the Laravel Storage facade / Flysystem, or raw move_uploaded_file against a public path?
3. Which anomaly/streams-platform and Laravel constraints are declared in composer.json, and does it pass composer why-not against our pinned platform?
4. Is there any validation configuration (max size, extensions, image dimensions) exposed to the admin, or is it hardcoded?
5. What happens to the underlying file when an entry is deleted or the field value is cleared?

Integration Approach

Stack fit. Treat this as a PyroCMS-module dependency, not a Laravel package. If the target is a greenfield Laravel build, the correct analogue is Spatie laravel-medialibrary, a Filament FileUpload, or a custom Streams field type wrapping the Files module — not this repo. The only justified adoption scenario is an existing Streams/OpenClassify deployment that already depends on the visiosoft addon family and wants a minimal single-file input alongside it.

Migration path. Two viable routes. (a) In-place: install into the addon path, publish assets, add the field to the relevant stream assignment, and write a one-off data migration mapping the existing column (likely a plain string path) into the new field's expected shape — then reconcile any files that live outside the assumed disk. (b) Fork-and-own: vendor the repository into a private VCS, add a composer.json version constraint and a test harness, and treat it as first-party code. Given the abandonment profile, (b) is the realistic path for anything beyond a prototype.

Compatibility. Pin the full graph before writing code: anomaly/streams-platform, Laravel minor, PHP minor, and the Files module if present. Run composer why-not to surface conflicts. Verify Twig input view rendering, asset publishing (php artisan addon:publish), and that the field type appears in the admin field-type list post-install. If the host is on PHP 8+, expect to patch type hints and deprecated dynamic-property access.

Sequencing.

1. Compatibility spike against a disposable copy of the host app (half a day).
2. Source read of the field type class and input view to answer the storage/validation questions above.
3. Security review of the upload handler; add server-side validation if absent.
4. Fork to private VCS with CI and at least save/read/delete round-trip tests.
5. Only then migrate field assignments and backfill data, behind a feature flag on one stream first.

Operational Impact

Maintenance. Effectively unmaintained upstream. Budget for a named owner and roughly a few days per year of patch work (PHP/Laravel upgrades, security follow-ups), plus the cost of tracking the Streams Platform's own upgrade cadence. Without a fork, every Laravel major is a blocking risk.

Support. Community-only, and thin: a zero-star repo with no issue traffic means no institutional knowledge to draw on. Internal runbooks and a documented field-type contract are mandatory, not optional.

Scaling. File uploads shift the scaling problem from the database to object storage. Confirm the addon writes to a configured disk rather than a hardcoded public/uploads path; if the latter, S3/CDN offload, multi-node deployments, and containerized ephemeral filesystems all break. Also watch request-body and PHP upload_max_filesize/post_max_size limits, which this package almost certainly does not address, and storage growth with no lifecycle policy for orphans.

Failure modes. Most likely: uploads succeed but the persisted path is wrong after a disk or app-URL change; entries deleted without file cleanup, producing unbounded storage creep; asset publishing skipped after deploy, leaving a broken admin input; silent failures on large files surfacing as empty field values; and hard failures on PHP/Laravel upgrades with no upstream fix. Each needs a detection signal — a storage-to-database reconciliation job is the single highest-value operational control here.

Ramp-up. Low for a developer fluent in Streams Platform addon conventions (service provider, field type class, Twig views, assignment config) — perhaps half a day. High for anyone else: the concepts are PyroCMS-specific, documentation is essentially the code, and there is no community to ask. Assume the person who integrates this also becomes its permanent owner.