Mpdf Bundle Laravel Package

Technical Evaluation

Architecture fit

• Fundamental mismatch: this is a Symfony bundle, not a Laravel package. The package name (vel/mpdf-bundle), description, and repository (astterx/MpdfBundle) all indicate a Symfony Bundle — a class extending Symfony\Component\HttpKernel\Bundle\Bundle plus a DI Extension and Configuration class. Laravel has no bundle-registration mechanism; it uses Illuminate\Support\ServiceProvider with package discovery via extra.laravel.providers in composer.json. Neither will be present here.
• The value proposition is thin for Laravel. The bundle appears to be a convenience wrapper that registers mPDF as a container service and injects a KernelInterface-derived cache/temp path. Under Laravel we would not use the Symfony container semantics, the bundle registration, the Configuration tree, or the kernel-aware path resolution. What remains is a thin factory around mpdf/mpdf — roughly a service provider and a singleton binding that any Laravel engineer writes in under an hour.
• The upstream dependency is the real asset, not this wrapper. mpdf/mpdf is a mature, framework-agnostic, PHP-library-first PDF renderer. It integrates cleanly into Laravel without any Symfony bridge. Adopting the bundle to get mPDF is a transitive-dependency decision disguised as a package decision.

Integration feasibility

• Technically possible, operationally pointless. A Laravel engineer could composer require the package, skip bundle registration, and manually instantiate the wrapper class. But that class will almost certainly type-hint Symfony interfaces (ContainerInterface, KernelInterface, ConfigCacheFactoryInterface) that Laravel does not bind, forcing us to build adapter bindings purely to satisfy a wrapper we don't need.
• Symfony version constraints are likely to collide. Bundles of this vintage and popularity typically pin symfony/framework-bundle and symfony/http-kernel to older major versions. Installing alongside a modern Laravel skeleton (which pulls its own Symfony components for console, HTTP foundation, and process at current major versions) risks a Composer conflict or forces us to pin Symfony components backwards — a change with blast radius across the whole application.
• No path to greenfield benefit. There is no Laravel facade, no config publish tag, no artisan command, no Blade directive, no testing helpers. Everything a Laravel developer expects from a package is absent.

Technical risk

• Adoption signal is effectively zero. 2 stars, 0 dependents, score 0.01. Zero dependents means no production user has validated this against any Symfony version, let alone a Laravel stack. There is no community to surface breakage.
• Maintenance status is the dominant risk. A bundle with this little traction is very likely unmaintained. mPDF itself has had security-relevant releases (temp-file handling, image/HTML parsing); a stale wrapper that pins an old mpdf/mpdf constraint will hold us on a vulnerable transitive version, and we cannot patch it without forking.
• Supply chain and provenance. Single-author repository, low visibility, and a namespace (vel) that is not obviously the author's own GitHub org (astterx). Before any adoption we would need to review the commit history, CI status, and whether releases are tagged and signed.
• License is fine. MIT is compatible with our use and imposes no obligations beyond attribution — this is the one clean signal in the package.
• Fork liability. If we adopt and the author disappears, we own the fork. Given that the wrapper is perhaps 100–200 lines, the fork is cheaper to write from scratch than to inherit.

Key questions

1. What is the actual driver — do we need HTML-to-PDF generation, and is mPDF already the chosen renderer, or is this package driving the renderer choice?
2. What Symfony and PHP version constraints does its composer.json declare, and does composer why-not resolve cleanly against the target Laravel skeleton?
3. Which specific capability of the wrapper (service registration, config tree, font/cache path resolution) do we believe we cannot replicate in a Laravel service provider in under a day?
4. Is the repository actively maintained — commits in the last 12 months, tagged releases, CI passing, issues answered?
5. What mpdf/mpdf version does it pin, and is that version within the currently supported security window?
6. Are there existing PDF-generation requirements elsewhere in the estate (invoicing, statements, compliance documents) that should drive a single standardized approach rather than a per-project choice?

Integration Approach

Stack fit

• Recommendation: do not adopt this package. Integrate mpdf/mpdf directly and write a first-party Laravel service provider. The wrapper supplies no capability that survives the port to Laravel, and it introduces a Symfony-framework dependency into a stack that should not carry one.
• Target shape: composer require mpdf/mpdf, then a small internal package (or app/Support/Pdf) containing: a MpdfServiceProvider registering a singleton factory, a config/pdf.php with font directory, temp directory, and default paper size/orientation, and a thin PdfRenderer contract so tests can swap a fake. This is the standard, boring, and correct approach.
• Where the wrapper's ideas are still worth stealing: the bundle's one genuinely useful behavior is deriving writable font-cache and temp paths from the framework. We should replicate that deliberately — point tempDir and fontDir at storage/app/mpdf, not at the vendor directory (which is read-only in most container builds) and not at the system /tmp (which is often size-capped and shared).

Migration path

• If nothing is in production yet: there is no migration. This is a greenfield decision and the answer is a direct mpdf/mpdf integration.
• If a team has already prototyped with the bundle: extract the instantiation logic into our own provider, swap the type-hints from Symfony container interfaces to a plain configured factory, and delete the dependency. Expect this to be a sub-day task on any real codebase — a useful signal in itself about how little the package is contributing.
• If a Symfony service is being ported to Laravel: treat this as a rewrite of the binding, not a port of the package. The mPDF configuration surface (fonts, margins, headers/footers, CSS) carries over unchanged because it is mPDF's API, not the bundle's.

Compatibility

• PHP version ceiling. Verify the declared php constraint. A bundle with this adoption profile frequently caps below current PHP minors; if so, it cannot run on a current Laravel release at all and the decision is closed.
• Symfony component version conflict is the most likely hard blocker, as described above. Confirm with a throwaway composer require vel/mpdf-bundle --dry-run in a scratch copy of the target skeleton before spending any further evaluation time.
• mPDF's own known constraints will apply regardless of wrapper: no CSS grid, partial flexbox support, inconsistent handling of modern web fonts without configuration, and significant memory consumption on large documents. These are the real integration risks and they belong to mPDF, not to this package.

Sequencing

1. Kill the evaluation cheaply (½ day). Dry-run install against the target Laravel skeleton. A conflict ends the discussion and saves the rest.
2. Confirm the underlying requirement (1 day). Pin down document types, expected page counts, required CSS fidelity, and whether PDF/A or accessibility tagging is needed — mPDF's strengths and weaknesses should drive renderer selection, not a two-star wrapper.
3. Build the thin provider (1–2 days). Provider, config file, storage/app/mpdf paths, a PdfRenderer interface, and one feature test asserting a non-empty PDF with a known magic header.
4. Harden the runtime concerns (1–2 days). Memory limit for document generation, queue offloading for anything over a few pages, deterministic temp-file cleanup, and font assets baked into the image rather than downloaded at runtime.
5. Document the decision. Record the rationale for rejecting the bundle so the next engineer does not rediscover it and re-open the question.

Operational Impact

Maintenance

• Direct integration minimizes our surface area. One dependency (mpdf/mpdf) that is widely used and actively maintained, versus two (mpdf/mpdf plus an unmaintained bridge) where the bridge constrains our ability to patch the underlying library. Every wrapper is a version ceiling; this wrapper's ceiling is low.
• The bundle inverts upgrade economics. Adopting it makes Laravel and PHP upgrades contingent on a third party with no demonstrated maintenance cadence. We would be trading one day of integration work for an unbounded, recurring upgrade tax.
• Ownership is clearer without it. A ~150-line internal provider is something the team can reason about, test, and change without negotiating with an absent maintainer.

Support

• No support channel. No dependents means no Stack Overflow corpus, no GitHub issue history of substance, no blog posts. Every problem becomes first-principles debugging.
• Internal capability exists and is cheap to build. PDF generation is well-trodden territory; the team does not need vendor support to bind a library into the container.
• Escalation path is the fork. With a package this small, "support" means "we maintain it," and if we are maintaining it anyway we should own it outright.

Scaling

• PDF generation is CPU- and memory-bound and belongs off the request path. This is true of mPDF regardless of wrapper choice, but it is the dominant scaling consideration. Render in a queued job, write to object storage, and return a signed URL, rather than streaming from a web request.
• Horizontal scaling requires shared or ephemeral-safe temp storage. Container filesystems are ephemeral and often read-only outside designated volumes; tempDir must point at a writable, per-worker path with cleanup, or concurrent renders will collide on temp filenames.
• Font caching is a cold-start cost. First render after a deploy pays a nontrivial penalty building the font cache. Bake the cache into the image or warm it during deploy, otherwise the first user after each release sees a slow response.
• Throughput ceiling is per-worker and modest. Budget worker concurrency against measured render time for the largest realistic document, not the average.

Failure modes

• Composer resolution failure at install time — the most likely failure, and the cheapest to discover. Test first.
• Runtime container-binding errors — Target [Symfony\...\KernelInterface] is not instantiable when the wrapper's constructor type-hints go unsatisfied. Symptomatic of the architectural mismatch; not worth patching around.
• Silent version drift — the wrapper pins an old mpdf/mpdf and we inherit unfixed upstream issues without any visible signal.
• Temp/font directory not writable — mPDF fails with opaque errors when tempDir or fontDir cannot be written. Fails loudly in dev, silently or partially in a read-only container under load.
• Memory exhaustion on large documents — mPDF loads the full document into memory; a 200-page HTML report can exceed a default memory_limit. Mitigate with a hard page/document cap and a queue with a raised limit.
• Output buffering / headers-already-sent corruption — streaming a PDF from a controller after any output has been flushed produces a corrupt file. Return a proper response object, never echo.
• Font substitution — missing fonts fall back silently, producing documents that render correctly in dev and wrong in production. Pin font assets in the repo.

Ramp-up

• Effectively zero for this package; low for the recommended path. There is no documentation, no examples, and no community to learn from — a new engineer has to read the source to understand it, which is a signal that reading the source of our own 150-line provider is the better use of that time.
• mPDF itself has a learning curve worth budgeting for: HTML/CSS subset limitations, header/footer templating with <htmlpageheader>, page-break control, and font configuration. That learning transfers to any project; learning this wrapper does not.
• Estimate: 2–4 engineer-days for the full direct integration (provider, config, tests, queue offload, deploy-time font warm-up, documentation). That is less than the time we would spend evaluating and working around the bundle.

Bottom line for the decision record: vel/mpdf-bundle is a low-adoption, likely unmaintained Symfony bundle whose only substantive function — registering mPDF in a DI container — does not transfer to Laravel. Reject it, adopt mpdf/mpdf directly behind a first-party Laravel service provider, and revisit only if the renderer requirement turns out to be something mPDF handles poorly.