Files Laravel Package

Product Decisions This Supports

• Document/file upload features in Laravel-based products: this package supplies the file-handling substrate (upload, storage, model attachment, MIME/type validation) so the team builds product features rather than re-implementing storage plumbing. Decisions it informs: whether file management is a build-vs-buy line item on the roadmap, and how much of the file feature set can be considered "already covered" when scoping a release.
• Scope of supported content types per release: 0.1.29 adds .xlsx and .zip support, expanding the set of files users can store and process. This directly feeds decisions like "can we accept spreadsheet imports via the file API?" and "can customers upload/download bulk asset bundles (zip) through our UI?" — each of which unlocks distinct use cases (bulk data import, export bundles, media packages, template distribution).
• Roadmap sequencing for import/export and bulk workflows: zip support is the usual prerequisite for "download all as archive" and "bulk import" features. Its arrival is a signal that those roadmap items are now cheaper to deliver and can be re-estimated.
• Whether to own or delegate the storage layer: adopting an opinionated LMS-ecosystem package means inheriting its model conventions, permissions assumptions, and release cadence. That is a strategic decision about platform coupling, not just a library choice.
• Risk/quality gating for dependent features: at 0.1.x the package is pre-1.0; minor versions can change behavior. This informs how much product surface you are willing to expose on top of it, and whether you need a compatibility shim or pinned version policy.
• Use cases now in reach: course/resource material uploads, spreadsheet-driven bulk enrollment or grade data, ZIP distribution of course assets, user-submitted documents with type restrictions, and downstream processing pipelines that assume a known MIME allowlist.

When to Consider This Package

Consider adopting when:

• You are building on Laravel and want file upload/storage/attachment behavior without designing it from scratch.
• You are already in or adjacent to the EscolaLMS/Wellms ecosystem — the package's conventions, auth assumptions, and data model will align with the rest of the platform, making integration cheap.
• Your requirements are conventional: upload, validate by type/size, attach to domain entities, serve/download, delete. Especially if your accepted file set is document-oriented (now including xlsx and zip).
• You can pin versions and absorb upgrade work — i.e. you have engineering capacity to track a fast-moving 0.1.x line and re-test on bumps.
• You want a short time-to-first-feature and are willing to accept a smaller community and thinner documentation than a mainstream alternative.

Look elsewhere when:

• You need a stable, versioned public API with semver guarantees. A 0.1.x dependency is a poor foundation for a long-lived, externally-facing contract.
• You require advanced media handling: image transformations, responsive derivatives, video transcoding, CDN orchestration, signed-URL policies at scale. Purpose-built media libraries or a cloud provider's SDK will be a better fit.
• You need multi-cloud or pluggable storage abstraction beyond what Laravel's filesystem already gives you, or strict data-residency controls.
• You have compliance obligations (retention, audit trails, virus scanning, DLP on uploads). This package is not a compliance product; you would be building that layer yourself.
• Your stack is not Laravel — the value proposition largely disappears.
• You are not in the EscolaLMS ecosystem and would have to fight its model/permission assumptions to fit a general-purpose app.

How to Pitch It (Stakeholders)

To executives: This is an existing open-source file-management component for our Laravel platform, and it just gained support for Excel spreadsheets and ZIP archives. Practically, that means two things: (1) features we had on the roadmap — bulk spreadsheet import and "download everything as a zip" — become meaningfully cheaper, because the underlying file handling now accepts those formats out of the box; and (2) we avoid spending engineering time rebuilding generic upload and storage plumbing. It is not a strategic bet on a vendor; it is a low-cost, reversible dependency that shortens delivery on document-centric features. The main caveat is maturity: the package is pre-1.0 and iterates quickly, so we should pin versions and budget a small amount of ongoing maintenance rather than assume it is set-and-forget.

To engineering: Adopt it as the file layer for Laravel services where requirements are standard upload/validate/attach/serve. The 0.1.29 release extends accepted types to .xlsx and .zip — verify the MIME allowlist and size limits are configurable to your needs, and confirm whether validation is extension-based or content-sniffed, since that difference matters for security. Treat the API as unstable: pin the version, wrap usage behind our own thin service/adapter so a future swap or a breaking minor bump doesn't ripple through feature code, and add integration tests around upload, type rejection, and download for the new formats. If we need image processing, transcoding, or upload scanning, plan for an additional component — this package won't cover it.

To product/design: Users can now attach spreadsheet and archive files, so we can design flows around bulk data in and bundled assets out — e.g. importing rosters or grades from Excel, or delivering a course's materials as a single download. Confirm the UX for rejected file types and oversized uploads, since that error surface is now wider.