Pdf Parser Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony bundle, not a Laravel package, and that mismatch is the whole evaluation. Its entire contribution is a DI extension, a configuration tree, and a service definition that wires an underlying PDF parser into Symfony's container. In Laravel that value proposition evaporates — the equivalent is a one-line singleton binding in a service provider we already own. Adopting it would mean pulling Symfony's dependency-injection, config, and http-kernel components into a Laravel app to obtain a service locator we can write ourselves in ten lines. Score 0, zero stars, zero dependents confirms there is no ecosystem signal to weigh against that structural mismatch.

Integration feasibility. Technically possible, practically not worth it. Laravel performs no bundle auto-discovery, so KreatysPdfParserBundle::load() is never called and the bundle's Extension/Configuration classes never execute. A developer would end up instantiating the wrapper's Service/PdfParser.php by hand — at which point the only artifact actually in use is smplot/pdfparser, the dependency, not the package under evaluation. We would be carrying a package whose DI machinery is dead code in our runtime.

Technical risk.

• Zero validation signal. No stars, no dependents, no production usage to learn from, no issue history to mine for known failure modes. Every edge case is ours to discover.
• Abandonment. A thin wrapper with no activity is a fork liability, not an asset. We would inherit maintenance of the wrapper and, effectively, of the wrapped parser.
• Upstream ambiguity. smplot/pdfparser is a derivative of smalot/pdfparser. The lineage must be checked for divergence, stale patches, and PHP 8.2+ compatibility before any dependency decision.
• Untrusted-input surface. PDF parsing is an attack surface regardless of wrapper: malformed object graphs, decompression bombs, deeply nested page trees, memory exhaustion. A wrapper adds a layer, not a defense.
• No security disclosure path. No advisory channel or CVE feed visible; a vulnerability would surface through our own incident, not a notification.
• Silent-success failure. Scanned or image-only PDFs typically extract to an empty string with no error — the most dangerous outcome, because it is indistinguishable from success unless we make it a distinct domain outcome.

Key questions.

1. Which library is actually maintained — smalot/pdfparser or the smplot fork — and what is commit recency and PHP version matrix for each?
2. Does the wrapper pin the underlying parser to an old major, and would we inherit that pin?
3. What are the licenses of the bundle and the wrapped library (MIT expected, unverified)?
4. Is extraction synchronous only, or does the wrapper expose streaming/chunking for large files?
5. Are there tests, CI, and tagged releases, or is this a single-commit scaffold?
6. What is in scope — text layer, metadata, forms, encrypted documents — and what is the documented behavior on image-only PDFs?

Integration Approach

Stack fit. Laravel 10–12 on PHP 8.2+. The bundle's Symfony constraints are the blocker: Symfony 3/4-era bundles commonly cap symfony/* at versions that conflict with a modern Laravel's transitive Symfony packages (symfony/console, symfony/http-foundation, symfony/process). Expect a Composer solver failure or a downgrade cascade. Reading the composer.json require block is the first gate; a conflict there ends the evaluation.

Migration path (recommended). Do not install the bundle. Instead:

1. composer require the maintained upstream (smalot/pdfparser or a verified alternative) directly.
2. Bind it as a singleton behind a first-party contract — e.g. App\Contracts\PdfTextExtractor — in a PdfServiceProvider. This preserves the one genuine benefit a wrapper offers (swappability) without the wrapper.
3. If the bundle's convenience API is preferred, replicate its wiring by hand; it is a constructor argument and a config array at most.

Compatibility. Confirm PHP constraint, psr/log version, and whether the parser requires ext-mbstring or ext-zlib in the base image. Check for global state or static caches that would misbehave under Octane's long-lived workers — the most likely runtime surprise in a Laravel deployment. Note the wrapper is stateful (parseFile() then getText()), so a naive singleton binding risks data bleed across requests under Octane; bind non-singleton or reset explicitly.

Sequencing.

1. Spike: extract text from a 20-file corpus (clean, encrypted, scanned, malformed, 50MB+) to establish capability and cost baseline against our real documents.
2. Dependency decision on the upstream library, not on this bundle.
3. Contract + service provider + adapter implementation.
4. Move extraction off the request path into queued jobs with per-job timeouts and memory caps.
5. Regression suite over the corpus, added to CI, before any user-facing exposure.

Operational Impact

Maintenance. We would own it. No release cadence, no upstream triage, no dependency-bump PRs. If adopted anyway, pin the exact version, vendor any patch we apply, and record an explicit owner and review date — otherwise it becomes an unowned transitive dependency that silently ages out of PHP compatibility.

Support. None available. No maintainer responsiveness to test, no documented troubleshooting, no community to escalate to. Internal documentation and a runbook are prerequisites, not follow-ups.

Scaling. PDF parsing is CPU- and memory-bound and does not scale by adding web workers. The correct shape is a dedicated queue with its own worker pool, conservative memory_limit, retry_after exceeding the extraction timeout, and a hard cap on accepted file size. Synchronous extraction in a request cycle is the primary scaling failure mode and should be treated as out of scope from the start. Pure-PHP parsing will also underperform pdftotext (Poppler) via subprocess or a dedicated extraction service on large or high-volume files.

Failure modes.

• Corrupt or truncated PDF → parser exception; must map to a domain error, not a 500.
• Encrypted/password-protected file → empty result or exception depending on code path; needs explicit handling and a user-facing message.
• Scanned image-only PDF → extraction succeeds and returns empty string. Must be modeled as a distinct outcome that triggers OCR or manual review, never as valid empty text.
• Decompression bomb / adversarial file → memory exhaustion killing the queue worker and, depending on supervisor config, the pool.
• Oversized file → timeout; without idempotency keys, retries duplicate work.
• Encoding/multibyte issues in extracted text → corrupted downstream storage; validate charset at the boundary.

Ramp-up. Low on the wrapper itself — a new engineer can read it in an afternoon, which is also the indictment: there is nothing there to learn. Moderate on the PDF domain: the team must internalize that extracted text is untrusted, frequently incomplete, and never a faithful representation of the document. Budget the real ramp-up time for the corpus-driven test suite and the queue hardening, not for the package.