Files Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-platform-primitive: The most valuable decision this package informs is a negative one. For "simple file handling" (upload, store, attach, retrieve, delete, path abstraction), Laravel's native Storage facade plus Flysystem already delivers the capability, is first-party, actively maintained, and MIT-licensed. The correct product call is do not add a dependency — use what the framework already ships. This package is a useful benchmark for confirming that file-API plumbing is commoditized, not a candidate to build on.
• Licensing gate as a roadmap input: The decisive product fact is GPL-2.0, not the feature list. Any proprietary, SaaS, or commercially licensed product faces copyleft obligations that typically end the evaluation before engineering time is spent. Treat this as the first filter on any future dependency, not an edge case.
• Attachment model reference (not adoption): Its advertised features — polymorphic attachments to any Eloquent model, configurable disks/paths, validation and metadata, extensible storage/processing hooks — describe the shape of a file-to-model relationship we may still want. We can satisfy that shape with native Laravel relationships plus Storage, or with spatie/laravel-medialibrary if media features are needed. Use this package as a spec sketch, not a dependency.
• Feature-scoping discipline: Where file handling is a real product differentiator (image conversions, thumbnails, virus scanning, retention policy, signed/chunked uploads, provenance/versioning), the leverage comes from product features layered on a maintained storage layer — never from a thin file-manager wrapper. This package sharpens that boundary.
• Risk posture for third-party dependencies: Zero stars, zero dependents, apparent single maintainer, and no observable security process make this a canonical "reject" example. File handling is an adversarial surface (path traversal, MIME/extension mismatch, zip bombs, TOCTOU on rename, symlink escape, orphaned files on rollback). A dependency with no security disclosure channel must be assumed unsafe until audited.

When to Consider This Package

Consider it only under a narrow, mostly disqualifying set of conditions:

• You are maintaining an existing PHP codebase that already imports it and removal costs more than keeping it (unlikely — zero dependents suggests almost nobody does).
• Your product is itself GPL-2.0 compatible — i.e., you ship open-source software under GPL-2.0 or a compatible license. Closed-source, SaaS, or commercially licensed products should stop here.
• The scope is genuinely trivial, internal, and non-adversarial: no untrusted uploads, no compliance or retention requirements, no long maintenance horizon.
• A timeboxed spike has demonstrated a concrete, quantifiable gap versus the framework's native storage, and legal has signed off.

Look elsewhere when:

• You are on Laravel — use the Storage facade over Flysystem. Same conceptual API, zero new dependencies, first-party maintenance.
• You need media features — conversions, responsive images, collections: spatie/laravel-medialibrary with intervention/image, both mature and permissively licensed.
• You need hardening — virus scanning, MIME validation, chunked uploads, signed URLs: require actively maintained libraries with a security process.
• Licensing matters at all (it almost always does) — prefer MIT/Apache-2.0 and avoid counsel review on every release.
• You need a maintenance guarantee — zero stars and zero dependents is a strong proxy for abandoned or never-adopted, with no community to absorb a handoff.

How to Pitch It (Stakeholders)

For executives: We evaluated makinacorpus/files as a potential file-handling dependency and recommend against adoption, for three reasons in order of weight. First, it is licensed GPL-2.0, which imposes copyleft obligations incompatible with our proprietary product and would require legal review that would likely preclude use. Second, it has no adoption signal — zero stars, zero dependent projects, and an apparent single maintainer — meaning no community, no security response channel, and real abandonment risk on a security-sensitive surface. Third, it is functionally redundant with file-handling already in our framework. Net: it adds legal risk and maintenance risk while adding no capability. Recommendation: close the evaluation and rely on the existing storage layer.

For engineering: No action required beyond closing the ticket. When a file-abstraction need surfaces, use Laravel's Storage facade over Flysystem — same concepts, already in the stack, maintained by the framework. Reach for spatie/laravel-medialibrary only for media-specific features (conversions, responsive images, collections). If we ever revisit a third-party file library, sequence it as: legal review of the license first (cheap gate that can terminate the evaluation), then a half-day senior source read of the public API and filesystem primitives, then a 2–3 day spike behind our own internal interface so the dependency is never referenced directly from controllers, jobs, or domain services — and default to the framework unless the spike proves a real advantage. The one durable takeaway from this evaluation is procedural: a 30-second check of license and dependent count before any dependency enters composer.json would have flagged this one immediately.