Files Field Type Laravel Package

Technical Evaluation

Architecture fit

anomaly/files-field_type is not a general-purpose Laravel package — it is a field type addon for the Streams Platform (the PyroCMS v3+ successor, developed by Anomaly Labs). It plugs into Streams' field-type registry to give stream entries a "multiple files" upload input, backed by the platform's file storage abstraction (files module / file fields). Architectural fit is therefore binary: if the target application is built on Streams/PyroCMS, it is a native citizen that inherits the platform's assignment, migration, and storage conventions. If the target is a conventional Laravel application (Eloquent, Blade, Livewire/Inertia, plain S3 disk config), there is no clean seam to integrate against — the package expects Streams' FieldType contract, addon manifest, and file repository, none of which exist outside the platform.

Integration feasibility

Low for greenfield. The repo shows a score of 0, no stars, and no dependents, which is the signature of an abandoned or purely internal addon rather than a maintained library. There is no evidence of CI, tagged releases, or a documented compatibility matrix. Realistically, integration means one of two paths: (a) adopting it inside an existing Streams install, where it is a drop-in addon under addons/ with a service provider and a field-type class; or (b) not integrating it at all and instead reimplementing the behavior on top of Laravel's native file upload primitives (a json/media column plus a Spatie MediaLibrary or custom HasMedia trait). Path (b) is typically 1–3 days of work and produces a maintainable asset; path (a) imports a dependency you cannot support.

Technical risk

High and concentrated in three places. First, abandonment risk: the Streams/PyroCMS ecosystem is effectively sunset, so PHP version, Laravel version, and framework-API drift will silently break the addon with no upstream fix. Second, unbounded dependency surface: field types pull in the platform kernel, which means the addon's stability is coupled to a large framework you also don't control. Third, security posture of multi-file upload: multiple-file handling needs per-file MIME/extension validation, size caps, path-traversal-safe naming, and orphaned-file cleanup on entry delete. A low-traffic addon with no dependents has almost certainly not been audited against these, and multi-file endpoints are a common attack surface. Treat any adoption as accepting the code as unmaintained.

Key questions

• Is the target application already running Streams/PyroCMS, or is this a greenfield Laravel build? (If greenfield, stop here.)
• What PHP and Laravel/Streams versions does the host run, and does the addon's composer.json/manifest actually permit them?
• Does the platform's files module handle storage, thumbnailing, and deletion, or does the addon own that logic?
• What is the file lifecycle on entry update/delete — are orphaned files garbage-collected?
• Are per-file validation rules configurable via the field type's rules()/settings, or hardcoded?
• Is there a supported fork or is the repo archived?

Integration Approach

Stack fit

Only fits a Streams Platform stack: PHP 7.x-era Laravel, the Streams kernel, the files module, and the addon bootstrapping convention. It does not fit a modern Laravel 10/11/12 application, a headless API, or a Livewire/Inertia front end without a rewrite. If the broader programme is standardising on current Laravel LTS, this package is off-strategy.

Migration path

For an existing Streams site: vendor or submodule the addon into addons/anomaly/files-field-type, register it, run the platform's addon install, then attach the field type to the relevant stream assignments and backfill existing single-file data if you are converting from a singular file field. Expect a data-shape change from a scalar file ID to an array/collection — that is the riskiest step and needs a scripted backfill plus a rollback path.

For everything else: do not migrate to it. The migration path is off the package — implement multi-file upload as a first-class domain concern using Laravel's Storage facade, a media/attachments table, form-request validation with array/mimes/max rules, and queued post-processing for thumbnails. That path is shorter than retrofitting Streams.

Compatibility

Assume narrow and undocumented: a specific Streams major version, an older PHP minor, and whatever Laravel the platform pinned. Verify by reading the addon manifest and composer.json constraints directly, then attempting an install in a throwaway environment before committing any estimate. Budget a spike, not a plan.

Sequencing

1. Confirm the platform decision (Streams vs. plain Laravel) — this gate decides everything downstream.
2. If Streams: spike the addon install in an isolated environment, verify upload, edit, and delete semantics, and audit file validation.
3. If not Streams: close out this evaluation and write a short build spec for the native implementation.
4. Regardless of path: define the file lifecycle contract (upload → validate → store → attach → orphan cleanup) before writing code, because that contract is what the addon gets wrong or leaves implicit.

Operational Impact

Maintenance

Effectively zero upstream maintenance. A score of 0 with no stars, no dependents, and an archived-adjacent ecosystem means your team becomes the de facto maintainer of any fork. Price that in: every PHP/Laravel upgrade becomes a manual compatibility review of addon code you did not write.

Support

No vendor support, no issue traffic to gauge, no community to escalate to. Internal knowledge will live with whoever integrates it — a single-point-of-failure risk. Document the addon's behaviour (especially storage paths and deletion semantics) at integration time or it will be archaeology later.

Scaling

The addon inherits the platform's synchronous upload handling. Multi-file uploads multiply request payload size, memory, and storage I/O per submission; without queueing, large batches will pressure PHP upload_max_filesize/post_max_size/max_file_uploads and the web tier's timeout budget. If expected volume is more than incidental (tens of files per entry, or high submission concurrency), plan for direct-to-object-storage uploads and an async attachment step — which means extending or replacing the addon's handling anyway, eroding its value further.

Failure modes

• Silent breakage on PHP/Laravel/platform upgrade with no upstream patch.
• Partial upload states: some files stored, entry save fails, orphans accumulate.
• Unvalidated file types slipping through if the field type defers validation to the platform's weaker defaults.
• Storage-path collisions or overwrites on same-named uploads.
• Entry deletion leaving files on disk, inflating storage cost and creating a data-retention/compliance exposure.
• Breakage of the admin UI if the platform's asset pipeline changes.

Ramp-up

Low ceiling, non-trivial floor. A developer unfamiliar with Streams needs to learn the FieldType contract, addon bootstrapping, and the files module before they can safely touch this — call it 2–4 days of ramp for the platform plus a day for the addon. For a team already on Streams, it's a few hours. For a team not on Streams, the ramp is not worth paying: reimplementing the capability natively costs less than the context-switching and carries none of the abandonment risk.

Recommendation

Do not adopt unless the application is already committed to the Streams Platform and this specific field type is already in use or trivially installable. In every other case, treat this repository as a reference implementation for how multi-file upload was modelled in that era, and build the capability directly on Laravel's file and storage primitives. The opportunity score of ~34 reflects a real feature need wrapped in a dependency that will not survive the next framework upgrade.