Simple Html Dom Bundle Laravel Package

Technical Evaluation

Bottom line: This is not a Laravel package. It is a Symfony2 bundle — a single service-container registration that exposes the abandoned simple_html_dom class as a service named simple_html_dom. In a Laravel application the bundle half is dead weight; only the underlying parser is usable, and it would have to be wired manually through a service provider. The capability (jQuery-style selectors over HTML) is still relevant; the artifact is not something to introduce into an active codebase.

Architecture fit

• The bundle consists of ErivelloSimpleHtmlDomBundle plus an AppKernel-era registration path. There is no configuration tree, no compiler pass, no autowiring, no interface to mock, and no tagged releases. Its entire value is one container entry.
• Laravel has no AppKernel, no bundle registry, and no service named simple_html_dom. Adopting this in Laravel means ignoring the bundle and hand-wrapping the legacy class in a ServiceProvider + facade — at which point you own 100% of the integration and have inherited 100% of the maintenance.
• Usage pattern ($this->container->get('simple_html_dom')) is Symfony 2 controller convention; on Symfony 3.4+ services are private and on Symfony 4+ app/AppKernel.php does not exist. The documented install path is not executable on any currently supported Symfony line, let alone Laravel.
• Effective verdict: fits Symfony 2.0–2.8, fits nothing current, fits Laravel only as an unmaintained third-party class you wire yourself.

Integration feasibility

• The only available Composer constraint is dev-master: no semver, no reproducibility, no changelog. Any upstream commit can silently change behavior — a supply-chain and CI-stability risk independent of the parser itself.
• The wrapper adds essentially no logic beyond service registration, so integration cost is dominated by the underlying library. Removing the Symfony layer does not remove the risk, it just moves the wiring onto our team.
• The underlying simplehtmldom is SourceForge-era and non-namespaced; the forks exist precisely because the original stalled. Expect PHP 8 deprecation/typing friction.

Technical risk

• Upstream abandonment (high): abandoned parser + abandoned wrapper compounds risk, and there is no upstream to escalate to.
• Security exposure (high if untrusted input): load('http://...') / file_get_html performs remote fetch. Any user- or third-party-controlled URL is an SSRF vector; entity handling and non-validating parsing warrant review before untrusted HTML touches it.
• Memory behavior (medium–high): the parser is known for retaining node trees. Long-running workers, Octane/Swoole/RoadRunner-style persistent runtimes, and queued jobs can exhaust memory unless clear() is called explicitly and documents are size-capped. A shared singleton service in a persistent runtime is a per-request leak risk.
• Correctness (medium): predates HTML5 parsing semantics; malformed real-world markup may parse differently than a browser, silently producing wrong extractions rather than errors.
• Adoption signal (low): 8 stars, 0 dependents, single maintainer, dev-master only, maturity "readme." No peer review, no downstream validation, no security advisory history — meaning absence of advisories is not evidence of safety.

Key questions to answer before any decision

1. Is the target actually Laravel, Symfony, or plain PHP? If Laravel or Symfony ≥4, the bundle is off the table and only the parser is even in scope — is the parser alone worth the risk?
2. Do we need selector-based HTML extraction, or specifically this API? Almost certainly the former, and Laravel/PHP already has safer options.
3. Is the HTML trusted (our own fixtures/templates) or untrusted (scraped, third-party, user-supplied)? This single answer moves remote-fetch and entity risks between "acceptable" and "blocker."
4. Who is the named owner and what is the budget for vendoring/forking if we proceed? No owner means no adoption.
5. Does an existing dependency already cover this? symfony/dom-crawler + CssSelector installs cleanly into Laravel and is typically already present transitively.

Integration Approach

Stack fit

• Laravel: do not install this bundle. It cannot be registered. If the Simple HTML DOM API is truly required, use voku/simple_html_dom (maintained fork, namespaced, modern PHP) behind a Laravel ServiceProvider.
• Preferred replacement, in order: (1) symfony/dom-crawler + CssSelector bound as a singleton, fed by Laravel's Http client or symfony/http-client — maintained, PSR-compliant, no exotic dependency surface; (2) voku/simple_html_dom if the team wants the legacy API preserved; (3) masterminds/html5 when strict HTML5 parsing is required.
• Keep HTTP and parsing separate regardless of choice: Laravel's Http facade gives retries, timeouts, and fakes for tests that load('http://...') cannot match.

Migration path

• Inventory call sites if anything already depends on this: load/file_get_html, find, ->href/->plaintext, clear().
• Introduce an application-owned interface, e.g. HtmlExtractor::query(string $html, string $selector): array, bound in a service provider. This decouples the app from whichever parser wins and makes the swap a one-file change.
• Reimplement behind that interface with DomCrawler (Crawler::filter()); most jQuery-style selectors map directly. Note differences in attribute access and text normalization and cover them with fixture tests — this is the step that catches silent extraction regressions.
• If a legacy Symfony 2/3 app genuinely requires the bundle, pin the underlying package by commit hash rather than dev-master, and vendor-fork both bundle and parser so we ship code we control.

Compatibility

• Verify PHP 8 compatibility explicitly against the vendor fork. Assume the original does not work and test; do not infer from the README, which targets PHP 5+.
• Confirm behavior under the target runtime: per-request FPM is fine, Octane/persistent workers require an explicit clear() and a non-singleton or resettable binding.

Sequencing

1. Confirm framework (Laravel vs Symfony vs plain PHP), PHP version, and the trust boundary for HTML input — 1–2 days. This gates everything.
2. Build the internal HtmlExtractor interface plus a DomCrawler-backed implementation with fixture tests — 2–4 days.
3. Only if a legacy app mandates the bundle: vendor-fork, pin by commit, add a service definition matching that Symfony version.
4. Do not adopt the bundle on new work under any circumstances.

Operational Impact

Maintenance

• Effectively zero upstream maintenance; adopting it means we inherit maintenance. No tagged releases means no upgrade path and no changelog to diff against — every composer update is an uncontrolled change.
• This is the dominant TPM cost: an unmaintained parser inside a product is a permanent low-grade tax on every PHP and framework upgrade, and it appears on every dependency-audit report we generate.

Support

• No community to escalate to: 8 stars, 0 dependents, single maintainer, no issue-triage history, no security advisories. Internal SLA only — any bug becomes a vendor-fork ticket for our team.
• Documentation is a README with one example; onboarding happens by reading source. Knowledge concentrates in whoever wrote the adapter, which is a bus-factor risk worth naming.

Scaling

• Memory-bound, not CPU-bound. Throughput scales only if clear() is called correctly and documents are size-capped. Under persistent runtimes the shared service instance is a per-request leak risk unless reset explicitly.
• Remote fetching inside request handling introduces network I/O in the request path — move it to async workers/queues with timeouts and byte caps regardless of parser choice. The parser is the wrong place to enforce that, so it must be enforced in the transport layer we own.

Failure modes to instrument

• OOM on large or deeply nested documents; watch worker RSS over time.
• Silent parse failures returning empty result sets rather than exceptions — extraction bugs surface as missing data downstream, so alert on row-count anomalies, not just errors.
• SSRF, DNS hangs, and timeout stalls if remote loading is permitted — requires allow-list, egress rules, and hard timeouts.
• Composer resolution drift from dev-master.
• Divergent output vs. browser parsing on malformed HTML, producing subtly wrong extractions that pass tests and fail business expectations.

Ramp-up

• Trivially easy to start — five-line API, jQuery-like selectors — and that ease is exactly what masks the failure modes above. Budget half a day of enablement on memory lifecycle, selector edge cases, and input trust boundaries; that training is really about the extraction pattern and carries over to whichever replacement we choose.
• Net assessment: low learning cost, high hidden operating cost, and a framework mismatch that makes the bundle itself irrelevant on Laravel. The interface-first approach captures the ergonomic benefit while keeping the swap to DomCrawler cheap — recommend that path, and treat this package as a reference implementation only.