- How do I install danteb918/livewire-pdf-preview in a Laravel app?
- Install it with composer require danteb918/livewire-pdf-preview, then run the package's Artisan install or publish command to copy the bundled PDF.js assets into your public directory. Check the README for the exact command name, because it was renamed in 1.0.2 and scripts referencing the old name will fail after upgrading. After publishing, clear your config and view caches and drop the Livewire viewer component into any Blade view.
- Does livewire-pdf-preview render PDFs on the server?
- No. The package vendors Mozilla's PDF.js and its worker, so the browser downloads and rasterises the file while Laravel only publishes assets and exposes configuration. That makes it a light fit when you want a preview without Ghostscript, Imagick, headless Chrome, queue workers or temp storage. It is not the right tool for server-side PDF manipulation, backend text extraction, or pixel-identical archival rendering.
- Which Laravel, PHP and Livewire versions does this package support?
- Because it is a Livewire component package, your Livewire major version matters as much as your Laravel and PHP constraints, so verify all three against composer.json before adopting. Confirm the constraints cover your current LTS target rather than assuming the latest release supports it. If you run an older Laravel or PHP version, test the install command and asset publishing on a staging copy first.
- How do I customize the PDF viewer's size and appearance?
- The viewer ships as a Blade-rendered Livewire component, so you can publish and override its views and configuration to control dimensions, container styling and defaults. Publish the package assets once, then edit the published files rather than the vendor copies so your changes survive updates. Wrap the component in your own layout or panel classes if you want the preview to match an existing dashboard or admin theme.
- Why do I get 'The API version does not match the Worker version' with PDF.js?
- PDF.js and its worker are a matched pair, so a stale published worker left behind after a composer update is the usual cause of this error. The fix is to explicitly delete previously published assets rather than overlaying new ones on top, republish, and clear the config and view caches. Bake that removal step into your deploy script so the mismatch cannot recur in other environments.
- Can I point the package at a custom PDF.js worker path or CDN?
- Version 1.0.2 added support for a custom worker path, which is useful for CDN-hosted assets, sub-path deployments and restrictive worker-src CSP rules. Check whether it is a config value or a per-invocation parameter, because that determines whether you set it once in config/ or thread it through every call site. Setting it globally in config is the cleaner option if the package allows it.
- Does livewire-pdf-preview work alongside Vite?
- It should coexist with Vite without conflict as long as the package assets are published into public/ rather than imported through your app bundle. If you do import them, the PDF.js worker has to be emitted as a separate entry point, which is the usual friction point. Confirm which pipeline the install command actually uses before wiring it into your build.
- What Content Security Policy headers do I need for the PDF preview to work?
- Browser-side PDF.js typically needs script-src and worker-src entries plus blob: allowances, otherwise the worker never loads and the viewer stays blank. The custom worker path added in 1.0.2 is the practical mitigation when your CSP restricts worker-src or your assets live on a CDN or sub-path. Test the preview in each environment after tightening headers, since a policy that works in one browser profile can fail in another.
- How do I test a Livewire component that uses the PDF preview?
- Unit-style Livewire tests can assert that the component mounts, receives the correct PDF URL or model, and renders the expected markup, but the actual rasterisation happens in the browser and cannot be verified that way. Use Laravel Dusk or another browser test to confirm the viewer loads and the worker resolves when you need end-to-end coverage. Keep a manual check for worker path and CSP changes, since those fail silently rather than throwing.
- Who is responsible for patching the bundled PDF.js when a security issue is disclosed?
- Because the PDF.js distribution is vendored into your public assets, it is invisible to Composer-based dependency scanning, so no automated alert will fire for you. Assign an internal owner to track upstream PDF.js security releases and schedule the composer update plus a clean republish when one lands. Pin the package version, and treat every PDF.js bump as a browser-compatibility change too, since recent majors require modern browser APIs.