Simple Html Dom Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a thin wrapper that exposes the (legacy) simple_html_dom parser through framework wiring — a Symfony-style bundle (...Bundle class, a namespaced config key) rather than a Laravel-native service provider + facade. For a Laravel codebase, fit is moderate at best: the parsing capability is usable, but the integration surface follows Symfony conventions and will need either a small adapter (service provider binding the parser, config published under config/) or direct instantiation of the underlying classes, bypassing the bundle entirely. The 2.0 release changes nothing about the architecture — it is a pure vendor/namespace rename — so any fit concerns from 1.x carry over unchanged.

Integration feasibility. Mechanically straightforward but multi-surface. The rename touches four distinct integration points, each of which can fail independently:

Namespace and class swaps are codemod-able (Rector, sed, IDE refactor). The config key rename is the sharp edge: it can appear in config/*.php, .env files, config() calls, container parameters, and any environment-specific deployment config outside the repo. A missed reference typically fails silently — the config resolves to null and the code falls back to defaults — rather than throwing.

Technical risk.

• No compatibility shim in the release notes. No mention of a class alias, a replace directive in composer.json, or a published upgrade guide beyond the four-line note. Assume a hard cutover.
• Versioning signal. Shipping a breaking rename as a major (2.0) is correct, but it also means the maintainer treats the rename as the headline change — there is no evidence in the notes of functional fixes, PHP 8.x compatibility work, or security patches. Consumers should not assume 2.0 fixes anything.
• Upstream dependency risk. simple_html_dom is a long-unmaintained parsing library with known PHP 8 deprecation and memory issues. The wrapper's health is capped by the underlying library's health, which the release notes do not address.
• Ownership change. A vendor rename (martyrer → mushroomcloud) usually signals a maintainer handoff or fork. Abandonment of the old Packagist name, security-advisory coverage, and future release cadence are all unknowns.
• Supply chain. New Packagist vendor means new trust surface; verify repository provenance, tag signing, and that the new package is the canonical continuation rather than an unaffiliated re-publish.

Key questions for the maintainer.

1. Is there a transitional release (1.x) that aliases the old namespace/bundle class and reads both config keys, so consumers can migrate code and config separately?
2. Is martyrer/simple-html-dom-bundle marked abandoned on Packagist with the new name as the suggested replacement?
3. Which PHP and framework versions are supported in 2.0, and were any compatibility fixes included alongside the rename?
4. What is the maintenance commitment for the new vendor — release cadence, security policy, bus factor?
5. Is the legacy simple_html_dom parser still the intended engine, or is a maintained replacement (e.g., symfony/dom-crawler, masterminds/html5) on the roadmap?

Integration Approach

Stack fit. PHP 8.x + Composer, framework-agnostic core. In a Laravel app, treat the bundle as an optional convenience layer: register a service provider that binds the parser, publish config under the new key, and avoid depending on Symfony bundle auto-registration. If the app only uses the parser in a handful of places, evaluating a direct dependency on a maintained DOM library is a cheaper long-term path than carrying the wrapper.

Migration path.

1. Inventory. Grep the whole estate — application repo, deployment configs, CI, infra-as-code, queue worker bootstraps — for martyrer, Martyrer, martyrer_simple_html_dom. Include compiled artifacts (cached config, bootstrap/cache/, optimized classmaps).
2. Branch and lock. Create a migration branch; confirm no transitive dependency pins the old package (composer why martyrer/simple-html-dom-bundle).
3. Swap the requirement. composer remove martyrer/simple-html-dom-bundle && composer require mushroomcloud/simple-html-dom-bundle:^2.0. Commit the lockfile.
4. Codemod references. Automated namespace/class replacement across app/, config/, tests/, and any string-based service IDs. Add a temporary CI grep gate that fails on any remaining martyrer occurrence.
5. Rename the config key in the published config file, .env, .env.example, and every config() / env() read site. Set the old and new keys side-by-side for one deploy if any config lives outside the repo.
6. Clear and rebuild caches: config:clear, cache:clear, composer dump-autoload -o, opcache reset on deploy.
7. Regress on parsing behavior — golden-file tests over representative HTML (malformed markup, large documents, encoding edge cases) before and after, since a rename should be behavior-neutral and any diff is a red flag.
8. Decommission the old package and remove the temporary grep gate once the estate is clean.

Compatibility. The rename is not backward compatible; old and new cannot coexist in one autoloader without a replace directive the release notes do not mention. Multi-service estates must migrate all consumers of a shared package together, or pin per-service and accept a temporarily mixed fleet. Watch for the config key being read by infrastructure that deploys independently of the application (e.g., worker images built from a different branch).

Sequencing. Ship as a single, small, isolated change rather than bundling it with feature work — the value of that discipline is that any parsing regression is unambiguously attributable to the rename. Roll out to a canary service first if the parser sits on a user-facing path, then widen. Budget a short window for stale-cache incidents immediately post-deploy.

Operational Impact

Maintenance. Ownership has moved to a new vendor; ongoing maintenance now depends on that maintainer's engagement, which the release notes give no signal on. Set a review checkpoint (e.g., 90 days) to confirm the new repository shows activity, responds to issues, and publishes advisories. Track the underlying simple_html_dom library separately — it is the real maintenance liability, and the wrapper cannot patch around its PHP-version or memory defects.

Support. Expect low support throughput. A single-maintainer, thin-wrapper package typically has no SLA, no LTS branch, and no backport policy; internal teams should be prepared to vendor the code or fork it. The absence of an upgrade guide or compatibility shim for a rename-only major is itself a signal about support ergonomics.

Scaling. Parsing cost is per-document, in-process, and memory-bound — simple_html_dom builds a full tree in PHP memory, which is materially heavier than streaming or native-extension alternatives. Under load this surfaces as worker memory growth and GC pressure rather than CPU saturation. Mitigations: cap document size before parsing, cache parsed/extracted results keyed by content hash, push bulk parsing to dedicated queue workers with tuned memory_limit, and keep the parser off latency-critical request paths. None of this is changed by 2.0.

Failure modes.

• Class-not-found on deploy — stale optimized classmap or opcache still referencing the old namespace. Detect via deploy smoke test that exercises a parse; fix with cache/opcache flush in the release step.
• Silent config regression — old key still set, new key absent; config resolves to null, parser runs on defaults. Detect with a startup assertion that the new key resolves; this is the highest-likelihood and lowest-visibility failure in the whole migration.
• Mixed-version fleet — some services on 1.x, some on 2.0, sharing parsed artifacts or serialized payloads carrying namespaced class names.
• Transitive pin — a third-party package requiring the old name resolves a duplicate or blocks the upgrade at composer update.
• Upstream abandonment — no new failure mode, but no fix path either if a PHP minor breaks the legacy parser.

Ramp-up. Low for the parser itself — the API is small and well-trodden — but the migration adds friction disproportionate to the code change: roughly half a day to a day for a typical single application, longer where config lives outside version control or where multiple services share the dependency. Document the new vendor name, namespace, and config key in the team's dependency register and onboarding notes at the same time, so the rename is not re-discovered by the next engineer who greps for the old name.