Input File Field Type Laravel Package

Product Decisions This Supports

• Feature scoping for admin-managed file attachments. The package is a Streams Platform (PyroCMS/OpenClassify lineage) custom field type that adds a generic "input file" field to stream definitions — i.e., it lets non-engineers attach a document/asset to a CMS entry from the admin UI. It supports decisions like "can we ship listing attachments (brochures, spec sheets, KYC docs, compliance PDFs) this quarter without custom form work?"
• Build vs. buy (and buy vs. write). The honest answer here is write: the scope is a single field type implementing the Streams field-type contract (form input, validation, storage, retrieval, display). At 0 stars, 0 dependents, and a last release of Feb 2022, this is best treated as a reference implementation for the field-type API rather than a dependency. A PM should price an internal equivalent at a few engineer-days, not a procurement cycle.
• Roadmap hygiene / dependency policy. Adopting it sets a precedent: a runtime dependency with no maintainer, no issues community, and no security response path. Use it as a concrete example when writing the "third-party dependency acceptance" checklist (maintenance signal, release cadence, transitive footprint, license).
• Ecosystem lock-in assessment. The package only makes sense if the platform is already Streams-based (OpenClassify/PyroCMS v1.x). It is a data point for the strategic question "do we stay on the visiosoft/OpenClassify stack or migrate?" — every extra niche addon increases migration cost.
• Migration/exit planning. If it is already in production, the decision it informs is "fork and own it" vs. "replace with platform-native uploads or spatie/laravel-medialibrary" — with a clear cost comparison, since the surface area is small.

When to Consider This Package

Consider it when:

• You are already running OpenClassify or PyroCMS/Streams Platform v1.x and need a generic file field without writing one; the integration cost is genuinely near zero because it plugs into the existing field-type registry.
• You need a working example of the Streams field-type contract (how a field type declares its input view, validates, persists, and renders) to copy internally.
• The requirement is deliberately narrow: one file per entry, local/S3 disk, no transformations — and you have an engineer who can own the code.

Look elsewhere when:

• You are not on the Streams Platform — the package is inert outside it; for modern Laravel use native Storage + Illuminate\Http\UploadedFile, or a maintained package such as spatie/laravel-medialibrary for collections, conversions, and multi-file galleries.
• You need image manipulation, thumbnails, multi-file galleries, versioning, or CDN delivery — out of scope here.
• You need security assurance: upload validation (MIME sniffing, extension allowlists, size caps, path-traversal and executable-file defenses), virus scanning, signed URLs, or private-disk access control. An unmaintained 2022 upload handler must be audited before it touches user-supplied files, and "audited by us" means you now own it.
• You require vendor support, an SLA, or a CVE response path — there is no active maintainer signal (0 stars, 0 dependents, single dated release).
• Your stack is on a newer Streams/Laravel major — compatibility with current framework versions is unverified; budget a spike before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a very small, unmaintained utility — a single file-upload field for a niche CMS framework. It has essentially no adoption (no stars, no downstream users, last touched in February 2022). It carries no license cost and no commercial upside, but also no support, no patches, and no security response. The recommendation is not to treat it as a strategic dependency: if the feature it enables is on the roadmap, fund a few engineer-days to implement or fork it under our own ownership, and keep the third-party footprint at zero. The business risk of adopting it as-is is a silent security and maintenance liability in the one part of the system that accepts user files.

For engineering (the ask): Evaluate it as a pattern, not a package. Confirm the target platform version, then either (a) fork it into our namespace, pin the commit, add tests for validation and storage paths, and add it to the owned-dependency register, or (b) reimplement the field type against the current Streams contract and drop the dependency. Either way: define the storage disk, enforce MIME/extension allowlists and size limits, keep uploads off the public web root unless explicitly intended, and document the exit path. Timebox the spike to one day; the code is small enough that a "no" is cheap.