Filament Upload Laravel Package

Product Decisions This Supports

• Build vs. buy for document intake in admin panels. If the product is a Laravel/Filament back office that needs users to upload a PDF and see it without leaving the page (contracts, invoices, onboarding paperwork, KYC documents, vendor certificates, applicant resumes), this package collapses what is normally a custom Filament field plus a JS viewer integration into a composer require. That is a real "buy" win for a small, well-bounded surface area.
• Roadmap sequencing for document-heavy workflows. Teams that keep deferring "attach and review documents" because the viewer work looks fiddly can pull it forward. It unblocks a demo-able intake → review loop, which is often the thing blocking a pilot with an ops or compliance stakeholder.
• Whether to standardize document review inside the admin panel versus routing users out to a separate DMS or an S3 presigned link. If reviewers live in Filament all day, inline preview reduces context-switching and support tickets; if documents are the core product surface, this is the wrong layer.
• Ecosystem leverage for a thin UI concern. A 45-star, zero-dependent package is best treated as a candidate accelerator, not a platform commitment. It informs a decision like: "spend hours integrating and a day hardening, rather than two to three days hand-rolling a FileUpload + pdf.js wrapper."
• Filament major-version strategy (new in v2.1.0). The package now explicitly spans Filament v3, v4, and v5.7+, with a fallback path for Filament's move away from the filament-forms::components.file-upload Blade view to an embedded renderer. That widens the window in which this is a viable placeholder while you plan a Filament upgrade, rather than a dependency that dies the moment you bump a major.
• Where it does not move the needle: it is not a document management system. It does not answer versioning, retention, annotations, e-signature, OCR, virus scanning, or access auditing. Do not let it anchor a roadmap for those.

When to Consider This Package

Consider it when:

• You are already on Filament (v3, v4, or v5.7+) and the need is narrow: upload a PDF, preview it inline, done.
• The consumer is internal ops staff or a small external user base, and the workflow is not regulated-critical.
• You want a spike or prototype fast and are comfortable owning the integration risk.
• Your team can absorb a small, single-maintainer dependency — i.e., you can read a few hundred lines of PHP and fork if needed.
• PDF is one of a handful of attachment types, not the product itself.
• You are on or moving to Filament v5.7+ — v2.1.0 is the release that makes that safe; pin at ^2.1.

Look elsewhere or build in-house when:

• License is unresolved. NOASSERTION is a procurement and legal blocker for commercial or enterprise distribution. This alone should stop adoption in a company with any OSS review process until clarified with the maintainer. Unchanged by v2.1.0 — this remains the single biggest gate.
• Adoption signals are thin. 45 stars, zero dependents, a single maintainer — that is a bus factor of one and no evidence of production hardening. v2.1.0 is one merged community PR; it is a positive maintenance signal, not evidence of production use. Treat it as unproven code, not a vetted dependency.
• You need real document capabilities: multi-page thumbnails, search, OCR, annotations, redaction, e-signature, large-file streaming, versioning, retention policies, malware scanning, or audit trails. This package is a form field, not a DMS.
• Security posture matters. Inline PDF rendering typically leans on a client-side renderer; you must understand the CSP implications, whether files are served through signed URLs, and whether uploads are validated beyond MIME type. An unreviewed package in a document path is an attack surface.
• You depend on Filament's stability contract. The v2.1.0 fix exists precisely because Filament changed an internal view name in a minor release. That tells you the package rides on Filament internals and will need periodic patching. If you cannot absorb a surprise break on a Filament patch upgrade, build the field in-house.
• You need SLAs or vendor support. There is none here.
• You are not on Filament. Zero value outside that ecosystem.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost accelerator for one specific thing — letting people upload and preview PDFs inside our admin panel. It could save us a couple of engineer-days on document-heavy internal tooling, and because it is a thin UI layer, the downside is capped: worst case we replace it in a day. The latest release (v2.1.0) is good news on one front — it restores compatibility with current Filament versions after an upstream change broke it, and it came via a community pull request that was accepted, so the maintainer is responsive. That removes our biggest technical caveat but not our biggest legal one. The license is still unclear, which is a procurement and legal risk we should not carry into anything customer-facing or revenue-bearing, and it is still a single-developer project with almost no adoption. Recommendation: pilot it in a non-critical internal workflow, gate any production use on license clarification and a short code review, and do not let it anchor a document-management roadmap. Treat the upgrade to v2.1.0 as a requirement if we are on Filament v5.7 or later.

To engineering: Treat this as a Filament form field with an embedded PDF viewer. v2.1.0 fixes a hard break on Filament v5.7+ where the filament-forms::components.file-upload Blade view was removed in favour of HasEmbeddedView; the component now falls back to toEmbeddedHtml() while remaining compatible with v3/v4. Pin at ^2.1 and drop anything below it on a v5.7+ app — v2.0.0 will throw "View [components.file-upload] not found." Before adopting: check how files are served (signed URLs vs. public paths), review upload validation and CSP implications, and confirm test coverage and dependency footprint. Note the maintenance implication: this fix proves the package tracks Filament internals closely enough to break on a Filament minor bump, so budget for reactive patching on Filament upgrades. If any of that is unsatisfactory, the fallback is a first-party FileUpload field plus our own viewer, which is a known, bounded piece of work. Also confirm the license with the maintainer in writing — NOASSERTION means we cannot assume permissive terms.

Signals to quote: score 15.7, opportunity 36.6 — i.e., a genuine unmet need in this corner of the Filament ecosystem, but adoption risk (45 stars, 0 dependents, single maintainer) is the dominant factor in the decision. The opportunity score justifies evaluating it; it does not justify depending on it. What has changed with v2.1.0: compatibility risk is down and the maintenance signal is (slightly) up; license risk and bus-factor risk are unchanged.