Simple Html Dom Bundle Laravel Package

Product Decisions This Supports

• Feature feasibility for HTML ingestion work. Any roadmap item that reads third-party or legacy HTML — price/availability monitoring, content import, meta-tag or link extraction, back-office table scraping, migration scripts — can be built with this. The package does not create new capability; it only removes a few lines of container wiring around an existing parser.
• The real build-vs-buy decision is one layer down. Adopting this bundle is not the decision. The decision it informs is Simple HTML DOM vs. a maintained parser (symfony/dom-crawler + symfony/css-selector, a maintained fork like voku/simple_html_dom, or PHP 8.4's native Dom\HTMLDocument). Treat the bundle as a footnote to that choice, not the choice itself.
• Stack-fit check (blocking). Despite being catalogued as a Laravel/PHP package, the *Bundle naming and DI structure mark this as a Symfony bundle. On a Laravel codebase it is inapplicable as shipped — no service provider, no facade, no auto-discovery. The decision reduces to requiring the underlying library and binding it ourselves.
• Dependency policy / technical-debt governance. Zero stars, zero dependents, Score 0, single maintainer. This supports a reject recommendation and a follow-on policy question: do we permit single-maintainer, no-ecosystem dependencies in the product graph at all?
• Where it genuinely fits: internal admin tooling, one-off migration scripts, prototype scrapers, short-lived content imports — low blast radius, no customer-facing SLA, disposable by design.

When to Consider This Package

Consider it when:

• You are on Symfony and want simple_html_dom available through the container with no glue code of your own.
• The work is a prototype or internal tool where the team already knows the selector API and speed-to-first-commit beats longevity.
• You are willing to fork or vendor the wrapper — it is small and trivially replaceable, so single-maintainer risk is mitigable.
• You accept the underlying library's constraints: non-spec, non-HTML5 parser, memory-heavy on large documents, inconsistent handling of malformed markup, PHP 8 compatibility caveats.

Look elsewhere when:

• You are on Laravel — a Symfony bundle does not apply; bind the library in your own service provider instead.
• You need a maintained dependency with release cadence and security response: prefer symfony/dom-crawler + symfony/css-selector, or a maintained fork if you specifically need the lenient parser.
• Content is JS-rendered — you need a headless browser (Panther, Playwright, Browsershot), not an HTML parser.
• The surface is customer-facing and long-lived, or subject to dependency review, SBOM generation, or CVE scanning.
• You require ecosystem support: zero dependents means no community-tested upgrade path, no issue triage, no downstream bug reports to lean on.

How to Pitch It (Stakeholders)

For executives: This is a convenience wrapper, not a platform component. It saves a handful of lines of container registration around an older HTML-parsing library, and it carries essentially no adoption signal — no stars, no dependents, one maintainer. Recommendation: do not add it to the stack. If a roadmap item needs HTML parsing, fund a short engineering slice to use maintained Symfony components instead, so we do not quietly inherit an unsupported dependency we will have to replace later — likely during a PHP or framework upgrade, at the worst possible time.

For engineering: It buys roughly twenty lines of DI registration in exchange for a dependency owner we do not control, wrapped around a legacy parser. Preferred path: symfony/dom-crawler + symfony/css-selector for spec-compliant work; keep any parser behind an application-owned HtmlExtractor interface so call sites stay swappable. If we genuinely need simple_html_dom's tolerance for broken markup, use a maintained fork and bind it ourselves — about thirty minutes of work, full control, no third-party wrapper in the graph. Also flag the metadata mismatch: this is a Symfony bundle, so it is off-limits for the Laravel services regardless of how the catalogue lists it.