- How do I install asmit/filament-upload in a Laravel app?
- Install it with composer require asmit/filament-upload, then register the plugin on the target Filament panel inside your PanelProvider. The runtime preconditions are PHP 8.1+, Livewire 3, and a Filament v3 panel. Pin the exact version in composer.json rather than a caret range, since a low release cadence plus fast-moving Filament majors makes silent patch drift a real hazard.
- Which Laravel and Filament versions does this package support?
- It is built for Filament v3 panels and expects PHP 8.1+ with Livewire 3, so it fits Laravel 10 and 11 applications running Filament v3. Behavior on Filament v4 is not verified, and the composer.json constraints for filament/filament and illuminate/* should be checked before you commit. Lock the Filament minor alongside the plugin and run composer why-not to confirm the resolution.
- How do I add a PDF upload field to a Filament resource form?
- Swap your existing FileUpload::make('...') definition for the package's field inside the resource's form schema; the rest of your Eloquent attachment setup stays the same. Registration is scoped to the panels that need it, and the integration is additive and reversible with a one-line revert plus composer remove. If the plugin imposes its own directory or disk convention, reconcile it with your existing storage policy first.
- Does the inline PDF preview use PDF.js or the browser's native viewer?
- The package renders a preview inline, but whether that is a native iframe/object embed or a bundled PDF.js build is not documented in the overview, so confirm with the maintainer. Either path touches your Content-Security-Policy through frame-src, object-src, and blob: directives. If PDF.js is bundled, verify the worker is published and respects a non-root asset URL, and include client-side rendering of untrusted documents in your security review.
- How are uploaded PDFs stored and served securely from a private disk?
- The field integrates with Laravel's filesystem abstraction, so files land on whichever disk you configure for the field. Private attachments require correct disk visibility, and serving them usually means signed or temporary URLs rather than a public disk path. Ask the maintainer explicitly how private-disk files are served before you rely on it for confidential documents.
- Does the package handle file size and mime type validation?
- The component includes validation and is constrained to application/pdf, but you should still enforce server-side rules such as mimes:pdf and max: on the field. Spike with a 10 KB, 10 MB, and 100 MB file to confirm the limits behave as expected against your PHP upload_max_filesize and post_max_size settings. Client-side checks are convenience, not a security boundary.
- What license is asmit/filament-upload released under, and can I use it commercially?
- No OSI license was detected, so the repository reports NOASSERTION and default copyright applies until the maintainer states otherwise. That means you have no clear right to use, modify, or redistribute it beyond viewing the source, which is a hard procurement gate rather than a footnote. Get written confirmation of MIT or Apache-2.0 before spending engineering time on integration.
- Can I use this package with Laravel Nova, Inertia, or a plain Laravel app?
- No. It is a presentation-layer Filament form field, so it has no insertion point outside a Filament panel. In a plain Laravel, Inertia, Nova, or custom-admin codebase it should be rejected outright. Adopt it only where Filament is already the admin UI.
- Is the package actively maintained, and what is the upgrade risk?
- It has roughly 45 stars, zero dependents, and a single maintainer, so the bus factor is one and there is no downstream validation of upgrades. Filament majors routinely break plugins, and a small plugin with no CI matrix will likely lag, meaning you effectively own the upgrade work. The listed last-release date is also anomalous, so verify actual tags and Packagist versions before trusting the metadata.
- Is it worth adopting versus building the field natively in Filament?
- The capability is roughly a FileUpload field constrained to application/pdf plus a custom preview Blade view, which benchmarks at well under one developer-day of native Filament work. Adoption has to be justified by polish and convenience rather than capability you cannot replicate. Spike it in a throwaway panel first, read the source (it is small), and check whether a test suite or CI exists before committing to production.