Pdfjs Bundle Laravel Package

Product Decisions This Supports

• Feature decision — in-app PDF viewing. This package is a thin Symfony bundle that serves Mozilla's PDF.js viewer assets and exposes a route to render PDFs in the browser. The real product decision it informs is "how do we let users view PDFs inside our product?" — not "should we adopt this specific bundle."
• Build vs. buy. PDF viewing is a commodity. The honest comparison set is: (a) browser-native <iframe>/<embed> — zero dependencies, zero cost; (b) raw PDF.js via npm/CDN — full control, no wrapper; (c) a commercial viewer (PSPDFKit, Apryse) if you need annotations, forms, e-signatures, or DRM; (d) this bundle — only if you are on Symfony and want the asset-serving plumbing done for you.
• Roadmap relevance. Contracts, invoices, statements, compliance documents, and admin-side report previews are the usual use cases. All are commodity features; none justify a custom rendering engine.
• Stack mismatch to resolve before anything else. The package is Symfony, not Laravel. In a Laravel codebase this is not directly installable — the viable path is PDF.js through npm/Vite, which is what you'd likely choose anyway. Treat "Laravel package" framing in the request as a misclassification.
• Vendor-risk signal. 0 stars, 0 dependents, score 0. This is an unvetted artifact. Any decision to use it should be framed as "fork and own the ~few hundred lines" rather than "add a dependency."

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony and want a bundle-managed route that serves the PDF.js worker and viewer assets.
• You cannot use a CDN — air-gapped deployment, strict CSP, data-residency, or offline-first requirements.
• You cannot rely on the browser's native PDF viewer — you need consistent rendering across clients, a text layer for selection/search, or a controlled toolbar.
• You are willing to pin and own the PDF.js version and audit the serving route (path traversal, Content-Disposition, cache headers, MIME sniffing).

Look elsewhere when:

• You are on Laravel — use pdfjs-dist via npm and a Vite entry; fewer moving parts than a Symfony bundle port.
• You need annotations, form filling, e-signatures, redaction, or DRM — go commercial; PDF.js does not do these well.
• You need server-side rendering or thumbnailing — use headless Chrome or a PDF-to-image service, not a browser viewer.
• You need maintained security patching — PDF.js has had XSS-relevant CVEs; an unmaintained wrapper with 0 dependents is a poor patching story.
• You need licensing certainty — verify both the bundle's license and the bundled PDF.js (Apache-2.0) before shipping.

How to Pitch It (Stakeholders)

For executives: "There's a free, open-source way to display PDFs inside the app instead of paying per-seat licensing to a document vendor. It's a very small, essentially unmaintained Symfony wrapper around Mozilla's PDF.js — the same engine Firefox uses. Code risk is low; maintenance risk is real, so we would fork it rather than depend on it. My recommendation is to prototype with the browser's built-in PDF viewer first, and only fall back to PDF.js if we need consistent rendering or text search across browsers."

For engineering: "It's Symfony, not Laravel — in our stack we'd use pdfjs-dist directly through npm and a Vite entry rather than port a bundle. If we do adopt the bundle, pin the PDF.js version, serve the worker and viewer assets ourselves, set a strict CSP with worker-src and object-src allowances, and review the asset route for path traversal before it touches production."

Recommendation: do not add as a dependency today. Prototype with browser-native PDF viewing; escalate to raw PDF.js only if a concrete requirement (cross-browser consistency, text-layer search, controlled UI) justifies it. Revisit the bundle only if we standardize on Symfony and need an offline-capable asset path.