Product Decisions This Supports
- Whether in-app PDF viewing is a feature worth owning. Requests like "let users preview invoices/contracts/statements without downloading" land in every B2B SaaS backlog. This package is evidence that the cheapest viable answer is not a PHP package — it's Mozilla's PDF.js rendered client-side. That reframes the decision from "which vendor/bundle do we buy?" to "how thin is our wrapper?"
- Build vs. buy for document viewing. The bundle only wires PDF.js assets into a Symfony 4 app; it adds no rendering, security, or workflow capability of its own. The genuine build-vs-buy axis is: (a) integrate PDF.js yourself (Apache-2.0-adjacent, MPL-2.0, actively maintained, free), or (b) buy a commercial SDK (Nutrient/PSPDFKit, Apryse, Adobe) when you need annotation persistence, redaction, form filling, e-signatures, or DRM.
- Framework-fit triage. It is a Symfony 4 bundle, not a Laravel package — despite the "Laravel/PHP" framing, there is no service provider, no config publish, no Blade/Eloquent surface. For a Laravel roadmap this is at best a reference implementation for how to register a PDF.js viewer (routes, asset paths, Twig template), not a dependency.
- Roadmap sequencing. Viewing is a low-cost, high-visibility win you can ship in a sprint. Annotation, search indexing, and signed-document workflows are a different tier of investment and should be scoped separately rather than smuggled in via a viewer bundle.
- Legacy portfolio decisions. If you still run Symfony 4, this is a signal about your stack, not the package: Symfony 4.4 reached end-of-life in November 2023. The right PM decision is a framework upgrade path, not adopting a 2018 bundle to decorate it.
- Risk posture on third-party UI code. Zero dependents, 10 stars, last release March 2018 — a clear "no upstream support" signal. Useful as a pattern; unusable as a supply-chain dependency for anything customer-facing.
When to Consider This Package
Consider it (narrowly) when all of the following hold:
- You maintain a Symfony 4 application that is frozen or nearing replacement, and you need a PDF viewer embedded with minimal code.
- The viewer is internal-only (admin back office, ops tooling) where cosmetic drift and missing security patches are tolerable.
- You accept pinning and patching the bundled PDF.js yourself — the package ships a specific PDF.js version from 2018, which predates multiple PDF.js security advisories. You must treat the bundled JS as your own code to audit.
- You need nothing beyond display: no annotation, no form fields, no text search UI, no server-side rendering, no redaction.
Look elsewhere when:
- You are on Laravel or any non-Symfony PHP stack. Wrong abstraction; porting effort exceeds just using PDF.js. Wire the
pdfjs-dist build into your asset pipeline and mount a viewer in a Blade component or isolated <iframe>.
- You are on Symfony 5/6/7 or PHP 8+. Bundle conventions, autowiring, and DI config have moved on; 2018 bundles are a compatibility liability.
- You need enterprise document features — annotation storage, redaction, digital signatures, OCR, conversion, DRM/watermarking. Buy a commercial SDK; you will not get there from a viewer wrapper.
- You have compliance, accessibility, or CVE-SLA obligations. An unmaintained 2018 wrapper with zero dependents fails any reasonable third-party risk review.
- Browser-native viewing is acceptable. For many internal use cases an
<iframe src="…pdf"> or a signed, time-limited download link is the correct, zero-dependency answer. Decide this before evaluating any library.
How to Pitch It (Stakeholders)
For executives (30 seconds): We evaluated a small open-source Symfony bundle for showing PDFs in-app. It is a thin wrapper around Mozilla's PDF.js — the actual rendering engine — and has been unmaintained since 2018 with no downstream users. Recommendation: do not adopt it as a dependency. The underlying capability (PDF.js) is free, actively maintained, and costs us roughly a sprint-day to integrate directly, with no vendor lock-in and no licensing cost. If we later need annotation, redaction, or e-signatures, that is a separate buy decision against commercial document SDKs, not something this package provides. Net: the PDF viewing feature is cheap and low-risk; the package is not.
For engineering: Treat this repo as a pattern reference only — it shows the shape of a Symfony-side PDF.js integration (asset registration, viewer route, template mount) and nothing more. Our implementation should vendor pdfjs-dist directly, pin the version, include the worker file, serve it from our own asset pipeline, and isolate the viewer in a sandboxed iframe or a dedicated route with a tight CSP (worker-src, frame-ancestors) so untrusted PDFs can't reach application context. Serve documents through short-lived signed URLs and never expose raw storage paths. Add the pinned PDF.js version to our dependency-watch list so we pick up rendering CVEs ourselves. If we are still on Symfony 4 anywhere, flag that as a separate platform-risk item — the framework's end-of-life is a larger exposure than any viewer choice.