Simple Html Dom Bundle Laravel Package

Product Decisions This Supports

• Frames the build-vs-buy-vs-adopt call for any HTML extraction feature. Roadmap items that need to read structured data out of third-party or legacy HTML — content migration, link/OG previews, price or listing monitoring, metadata harvesting, email-template or report parsing, sitemap crawling — land here first. This package is a candidate in that evaluation, not the answer to it.
• Sets the dependency-adoption risk bar. With 0 stars, 0 dependents, score 0.03, and a single-maintainer wrapper around a SourceForge-era library, this is a useful calibration point for what "unvetted dependency" looks like on paper. It supports a policy decision (minimum maintenance and security signals before a package enters the stack) more than a feature decision.
• Surfaces a framework-mismatch worth resolving early. Despite the roadmap assumption that "Laravel ecosystem = drop-in," this is a Symfony bundle, not a Laravel package — no service provider, facade, config publish, or Laravel-idiomatic wiring. That's a concrete example that informs how much effort you budget for third-party evaluation generally.
• Drives the abstraction decision, which is the real product lever. The question isn't which parser; it's whether parsing sits behind an internal HtmlExtractor/HtmlParser contract so the library is swappable. Deciding this before three features depend on simple_html_dom's node API is cheap; deciding it after is expensive.
• Collapses the "scraping tooling spike" into a short list. Given the maintenance profile, the tooling question reduces to maintained options — symfony/dom-crawler + symfony/css-selector, voku/simple_html_dom (the maintained fork), PHP 8.4's native \Dom\HTMLDocument, or a headless browser for JS-rendered pages. That's a half-day spike, not a research project.

When to Consider This Package

Adopt only if all of the following are true:

• You are on a legacy Symfony 2/3-era codebase where this bundle is already installed and working, and removing it costs more than keeping it.
• The parsing target is well-formed, small, and internal — no adversarial or malformed markup.
• The code path is non-critical and failure is acceptable (a degraded preview card, not a checkout flow).
• You have explicitly accepted that you own the maintenance: pinning the version, patching PHP 8.x incompatibilities, and handling the upstream library's memory behavior on large documents.

Look elsewhere if any of these are true — which, for most Laravel product teams, is all of them:

• Greenfield or new feature work. Zero stars and zero dependents means no production feedback loop, no issue triage, no security disclosure process, and no semver discipline to reason about. You are the only QA.
• You need Laravel integration. No service provider, facade, or config surface. Hand-wiring a Symfony bundle into Laravel adds integration cost with none of the ecosystem benefit.
• You need ongoing upstream health. The underlying simple_html_dom library is effectively unmaintained: PHP 8.x deprecation and dynamic-property warnings, memory growth on large or deeply nested documents, and a parsing model that predates modern HTML5 error recovery.
• Correctness matters. On malformed real-world HTML, HTML5-compliant parsers behave measurably better than the legacy parser this wraps.
• You need JavaScript-rendered content. No parser solves this; you need a headless browser, and picking this package just schedules a rewrite later.

Recommended default: standardize on symfony/dom-crawler (works cleanly in Laravel, actively maintained, jQuery-style CSS selectors via symfony/css-selector), reach for PHP 8.4's native \Dom\HTMLDocument where you control the runtime, and treat this package as out of scope for new work.

How to Pitch It (Stakeholders)

To executives (30 seconds): We evaluated a community package for reading data out of web pages. It's a thin wrapper around an abandoned library, has no users, no maintainers beyond one person, and no security process. Adopting it would mean quietly taking on maintenance of someone else's code, with a rewrite likely within a year. A well-maintained alternative costs us nothing and carries a fraction of the risk. Recommendation: don't adopt this package; standardize on the maintained option and keep it behind an internal interface so the choice stays reversible. No budget impact, no timeline impact.

To engineering (the substance): This is a Symfony bundle, not a Laravel package — there's no service provider or facade, so "integration" means hand-wiring it yourself in a service provider in under an hour, at which point the wrapper adds a supply-chain hop (you trust iloh and the upstream) without adding capability. It wraps simplehtmldom, which is unmaintained and carries known PHP 8.x friction and memory-growth issues on large documents. With 0 stars and 0 dependents, there's no signal anyone runs this in production. Proposal: use symfony/dom-crawler + symfony/css-selector (often already a transitive dependency in Laravel stacks), wrap it in a small HtmlExtractor contract in our own namespace, and swap implementations in one place if we ever need to. If we specifically want simple_html_dom API ergonomics, use voku/simple_html_dom, the maintained fork. Time cost of the swap: hours — and it removes a single-maintainer dependency from our risk register.

To the delivery team (operational): Budget 1–2 engineer-days to adopt this safely, plus a recurring ~1 day/quarter of maintenance (PHP bumps, Composer audit noise, fork-and-patch process), versus roughly one day total for DomCrawler with no recurring tail. Known failure modes to plan around if it were adopted: silent parse degradation on malformed HTML, memory exhaustion in long-running queue workers, PHP 8 fatals after a runtime upgrade with no upstream fix, Composer resolution breakage from the transitive pin, and supply-chain exposure from an unaudited dependency. Ramp-up on the API is trivial — which is precisely the trap: low learning cost masks high ownership cost. Record the decision in an ADR either way.