Files Field Type Laravel Package

Product Decisions This Supports

• Attachment and document features on Streams/PyroCMS: If the product is built on the Anomaly Labs Streams Platform (PyroCMS 3.x lineage), this field type is the shortest path to a multi-file upload capability on any stream entity — no need to design a custom pivot table, upload handler, or admin UI.
• Build vs. buy for file fields: This is a "buy" (adopt) candidate specifically for the upload field primitive. It replaces an estimated 1–3 weeks of design, validation, storage-adapter, and admin-panel work with a composer dependency, provided the surrounding platform is already in place.
• Roadmap gating for media-heavy features: Client portals, support-ticket attachments, contract repositories, product spec libraries, and CMS page assets all depend on a repeatable multi-file field. Adopting this package unblocks those roadmap items without bespoke work.
• Scope decisions on what not to build: Adoption implies deferring richer DAM capabilities (versions, renditions, OCR, virus scanning, per-file permissions, granular quota enforcement) — these become explicit follow-on bets rather than prerequisites.
• Vendor and platform risk assessment: Zero stars, zero dependents, and a zero composite score make this a signal in itself. It informs the decision of whether the product should deepen its commitment to Streams or plan an abstraction/migration layer around file storage.

When to Consider This Package

Consider it when:

• The application runs on Anomaly Labs Streams Platform / PyroCMS 3.x and already uses Streams field types as its content model.
• The requirement is a straightforward "attach one or more files to a record" capability inside the existing admin/control panel.
• The team is comfortable owning a vendored dependency — forking it into the repo if necessary — rather than relying on upstream maintenance.
• The file volume, size, and compliance profile are modest (internal tools, marketing sites, small client portals).
• Time-to-first-demo matters more than long-term ecosystem support.

Look elsewhere when:

• The stack is vanilla Laravel, Livewire, Nova, Filament, or Inertia — mature first-party or Spatie/Intervention-based solutions cover the same ground with vastly larger communities.
• The product needs direct-to-S3/GCS presigned uploads, chunked/resumable transfers, client-side image transformation, or background processing pipelines.
• Requirements include virus scanning, DLP, per-file ACLs, audit trails, retention policies, or e-discovery — this package does not address them and would need to be wrapped comprehensively.
• Procurement requires active maintenance, security advisories, or a support contract. The repository metrics here (no stars, no dependents, no visible ecosystem) do not support that posture.
• There is any realistic chance of migrating off Streams. Without an abstraction layer, the field type's schema and storage conventions become migration debt.
• The team cannot afford to read and own the source. With no dependents, there is no community backstop for edge cases.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose component that gives our Streams-based product multi-file uploads on day one instead of a multi-week build. It is a tactical accelerator, not a strategic platform bet — the library itself has essentially no adoption, so we should treat it as code we own rather than a vendor we depend on. The decision to adopt it is really a decision to keep investing in the Streams stack; if that stack is on the roadmap for replacement, this package should not be adopted at all. Recommended posture: adopt behind an internal storage/attachment interface so the underlying implementation can be swapped without a product rewrite.

To engineering: The package supplies an Anomaly field type that registers a multi-file field against Streams entities, handling upload, persistence, and admin rendering. It is narrow and, by inspection, small enough to fork and maintain internally. Risks are concrete: no community, no dependents, no visible release cadence, and behavior tied to Streams' internals across versions. Ask: pin the version, vendor it, add tests around upload edge cases (large files, partial failures, orphaned records, deletion cascades), and route all file access through our own service layer rather than calling the field type directly. If we cannot commit to those guardrails, the correct answer is to build a thin internal equivalent — the surface area is genuinely small.