Xmldom Laravel Package

Product Decisions This Supports

• XML-heavy integrations (SOAP, XSD, feeds, sitemaps, EDI, legacy partner APIs): This package is a thin ergonomic wrapper over PHP's native DOMDocument, aimed at the most consistently painful part of XML work — namespace-aware element creation, node import, and traversal. It informs the build vs. buy vs. wrap question: do we hand-roll helper classes, adopt a wrapper, or write raw DOM code?
• Build-vs-buy on internal tooling: If a squad is considering a small internal XmlBuilder/DomHelper utility (a very common outcome of a SOAP integration), this package is the "buy" option to price against. It is a ~1-file abstraction, so the honest comparison is against 100–200 lines of in-house code, not against a platform.
• Ecosystem lock-in review: The package's only credible use case is as a transitive dependency of goetas-webservices/xsd2php / xsd-reader / soap-client style toolchains. That makes it a decision input for any XSD-to-PHP codegen or SOAP client evaluation, not a standalone roadmap item.
• Risk register / dependency policy: With 1 star, 0 dependents, an archived repository, and a composite score of ~0.05, it is a useful calibration example for a "minimum bar for new dependencies" policy — the kind of artifact that makes the case for an allow-list concrete.
• Roadmap signal: Non-support. This should not appear on a roadmap; it belongs in the "evaluated and rejected" log so the same question isn't re-litigated next quarter.

When to Consider This Package

Adopt only under a narrow, verifiable set of conditions:

• You are already committed to the goetas-webservices family (xsd2php, xsd-reader, soap-client) and this package arrives as a transitive constraint you cannot pin away — in which case you are managing it, not choosing it.
• You have confirmed the exact version resolution, you are vendoring or forking it internally, and you have accepted ownership of patches — because archived means no security fixes and no PHP 8.x/8.3 compatibility guarantees, and no Laravel 11/12 support statement.
• The usage surface is genuinely small (namespaced element creation and node import) so that a fork or a 150-line replacement is a realistic fallback.

Look elsewhere in every other case:

• Default for Laravel work: PHP's native DOMDocument + DOMXPath directly, optionally wrapped by your own small service class. No dependency, no archive risk, full control.
• Reading/scraping/manipulating HTML or XML from HTTP responses: symfony/dom-crawler — already adjacent to Laravel's Symfony dependency tree and actively maintained.
• Serialization / array-to-XML / XML-to-array: spatie/array-to-xml or sabre/xml for Laravel-friendly, maintained, documented options.
• Standards-heavy work (SOAP, XSD, WSDL): prefer maintained clients, or budget the integration as bespoke code rather than inheriting an archived micro-dependency.
• Any regulated or security-reviewed environment: archived + 1 star + 0 dependents fails a supply-chain review on maintenance and triage grounds alone.

How to Pitch It (Stakeholders)

Executives: A one-line summary — this is an abandoned micro-library for XML handling with essentially no user base, and we should not take a dependency on it. The cost of avoiding it is small: XML namespace handling can be solved with roughly a day of engineering or with maintained, mainstream alternatives. The cost of adopting it is unbounded: no security patches, no PHP-version guarantees, no community to notice a regression, and a future migration forced on our schedule rather than ours. Recommendation: do not adopt; record as evaluated and rejected.

Engineering: The problem it addresses is real — raw DOMDocument namespace handling is verbose and easy to get subtly wrong. But the solution here is a thin, unmaintained wrapper at a very low adoption score, with an archived upstream. The practical guidance is: use native DOMDocument behind a small internal service, or reach for symfony/dom-crawler / sabre/xml / spatie/array-to-xml depending on whether we're reading or writing. If this ever shows up as a transitive dependency of xsd2php or a SOAP toolchain, escalate it to an explicit fork-and-own decision rather than silently inheriting it.