- Can I use nti/pdfjs-bundle in a Laravel application?
- Not idiomatically. nti/pdfjs-bundle is a Symfony bundle that ships a Bundle class, Symfony DI configuration and Twig helpers, and Laravel has no bundle registration mechanism, Twig engine or container extension points that it targets. Composer-requiring it into a Laravel app will not give you a working viewer. The practical path is to treat it as a reference implementation, vendor the PDF.js assets yourself and rebuild the integration as a Blade component mounted through Vite.
- How does nti/pdfjs-bundle render PDFs in the browser?
- It integrates Mozilla's PDF.js and adds a controller, a route and a Twig helper so you can embed a PDF viewer without plugins or external desktop viewers. Viewer options such as toolbar visibility, zoom and rendering behaviour are configurable per document. The actual rendering work is done entirely by PDF.js; the bundle is a thin Symfony wrapper around those assets and configuration.
- Does nti/pdfjs-bundle support Laravel 10 or 11?
- No. The package is built for Symfony, so Laravel version support is not applicable because there is no service provider, facade or Blade integration to boot. There is also no published compatibility matrix for Laravel, and none is expected. You would need to reimplement the viewer mounting and PDF delivery yourself inside your Laravel app.
- What should I use instead of nti/pdfjs-bundle in Laravel?
- Install the PDF.js distribution directly from the official mozilla/pdf.js releases or the pdfjs-dist npm package, then bundle it with Vite. Build a Blade component that mounts the viewer against a route in your app, and keep the bundle's config shape only as a design reference for toolbar and zoom options. Pin the PDF.js version explicitly and record the upgrade path in your own repository.
- How do I display a PDF in a Blade view without a browser plugin?
- Serve the document through a controller that authorizes the request and returns a signed, time-limited URL with Content-Type: application/pdf and Accept-Ranges: bytes. Mount PDF.js in a small Vite entrypoint against that URL and render it inside a Blade component. Avoid iframe patterns that rely on file:// URLs or cross-origin embedding, since they break under most Content Security Policy setups.
- Does nti/pdfjs-bundle work with Vite or Laravel Mix?
- Not as shipped. The bundle publishes Symfony-oriented assets and has no Laravel asset pipeline integration, so there is nothing to wire into Vite or Mix. In a Laravel app you would install pdfjs-dist from npm, import it in your Vite entrypoint and point the viewer at your own PDF route instead.
- What are the security risks of adopting nti/pdfjs-bundle?
- PDF.js has a real CVE history covering arbitrary JavaScript execution in the viewer, XSS via crafted PDFs and sandbox escapes, and a wrapper that pins an old build inherits all of it. There is no visible release cadence, zero stars and zero dependents, so there is no evidence the maintainer would respond to an advisory or bump the bundled PDF.js version. Pulling PDF.js from upstream yourself and pinning a current release is the safer approach. Also verify the viewer's CSP requirements, since PDF.js historically needs worker-src and script-src allowances.
- Is nti/pdfjs-bundle actively maintained?
- There is no evidence of active maintenance. The package shows zero stars, zero dependents and no stated CI or test suite, and there is no visible release cadence to confirm it tracks upstream PDF.js. Treat it as a source of reference implementation rather than a dependency you can rely on for security updates.
- What license is nti/pdfjs-bundle released under?
- The license is unclear from the available package information, which is a problem if you plan to ship it in a commercial application. PDF.js itself is Apache-2.0 and safe to use directly. Confirm the wrapper's license terms before adopting any of its code, and prefer pulling PDF.js from the official source.
- Can PDF.js stream large PDFs with range requests in a Laravel app?
- Yes, provided your server responds with Accept-Ranges: bytes and honours the Range header so PDF.js can fetch the document incrementally instead of loading the whole file into memory. Implement this in your own controller using a streamed response rather than relying on the bundle, whose range-request behaviour is undocumented. Test with large multi-hundred-page documents to confirm the viewer does not block on a full download.