Simple Html Dom Bundle Laravel Package

Product Decisions This Supports

• Scraping/ingestion features: Any roadmap item that needs to parse arbitrary third-party HTML (competitor price monitoring, listing aggregation, content import, email/HTML normalization) can lean on this bundle instead of a custom DOM client. It wraps simple_html_dom — a forgiving, jQuery-style parser — behind a Symfony service, so PHP teams avoid the brittle DOMDocument/libxml error handling that usually eats a sprint.
• Build vs. buy (vs. DIY): This is a thin integration layer, not a scraping platform. It answers "do we wire up an HTML parser service in our container?" — not "do we build a scraping pipeline?" Scheduling, retries, rate limiting, proxy rotation, JS rendering, and anti-bot handling remain ours to build or buy elsewhere.
• Framework-fit question for Laravel: Note the framing — this is a Symfony bundle (MushroomCloudSimpleHtmlDomBundle), not a Laravel package. It's usable in Laravel via the service container, but auto-discovery, config publishing, and facades are Symfony-shaped. That's a real decision input if the team's default assumption was "drop-in Laravel package."
• Dependency surface / supply-chain review: The 2.0 release is a rename and namespace move only — no functional change. That makes it a decision about migration cost and maintainer churn, not capability.
• Migration sequencing: If anything already depends on martyrer/simple-html-dom-bundle, 2.0 is a hard break with no feature payoff, so it lands on a maintenance slot, not a roadmap slot.

When to Consider This Package

Consider it when:

• You need tolerant parsing of malformed real-world HTML (the common case for scraped pages) rather than strict XML-grade parsing.
• Your stack is already Symfony-centric, or Laravel plus a team comfortable registering Symfony-style bundles and editing config keys.
• The parsing need is narrow and internal: pull a few selectors out of a page, no JS execution, no browser automation.
• Volume is modest and you control the request layer (you're supplying the HTML, or fetching it with your own Guzzle/HTTP client).

Look elsewhere when:

• You need JavaScript-rendered pages (headless browser territory), distributed crawling, or proxy/retry infrastructure.
• You need standards-compliant HTML5 parsing at scale — symfony/dom-crawler + masterminds/html5 is better maintained, framework-native in Symfony, and gives you CSS selectors without an opaque wrapper.
• You need a Laravel-idiomatic package with auto-discovery, a facade, and publishable config.
• You are on the old martyrer/... package and have no capacity this cycle: the upgrade is pure breakage — namespace, bundle class, Composer name, and the config key martyrer_simple_htm_dom → mushroom_cloud_simple_html_dom all change. There is no reason to schedule it urgently; there is also no reason to expect the old name to receive fixes.
• A single-maintainer package rename with no functional delta is a caution flag: pin the version, and keep the parsing call behind our own adapter interface so a future swap is a one-file change.

How to Pitch It (Stakeholders)

For executives: This is a small integration library that lets our PHP engineers parse third-party web pages reliably and cheaply, instead of hand-rolling HTML handling in every project. It is not a scraping platform — it does not solve scheduling, scale, or bot-blocking, so it's a tactical build-vs-buy input, not a strategic bet.

For engineering: Version 2.0 is a maintainer rename only — martyrer/simple-html-dom-bundle → mushroomcloud/simple-html-dom-bundle. Composer name, namespace (MushroomCloud\SimpleHtmlDomBundle), bundle class (MushroomCloudSimpleHtmlDomBundle), and the config key (mushroom_cloud_simple_html_dom) all move. Nothing new is gained, and any existing usage breaks. Recommendation: keep parsing behind a thin in-house HtmlParser interface so this dependency stays swappable; migrate only when we're already touching that service, and pin the version in the meantime.

For planning: No roadmap item is unblocked or blocked by 2.0. Treat it as dependency hygiene on an existing service, not a feature delivery. If we adopt fresh, budget an afternoon for the Symfony-bundle-not-Laravel-package nuance (manual registration, non-standard config key) rather than assuming Laravel auto-discovery.