Zend Xml2Json Laravel Package

Product Decisions This Supports

• Integration scoping for XML-based partners. This library answers one narrow question — "can we turn an incoming XML payload into a JSON-shaped array without writing a parser?" — which is the first decision gate on any partner feed, sitemap ingest, SOAP-adjacent API, EDI/cargo/banking file drop, or legacy export pipeline. Treat it as a prototype enabler, not a production commitment.
• Build vs. buy vs. borrow. The real decision this informs is not "buy" (it's free) but "borrow vs. write in-house vs. adopt a maintained fork." The library is a thin wrapper over PHP's DOMDocument with an Xml2Json::fromXml($xml, $ignoreExceptions) entry point returning a JsonSerializable. A competent engineer replicates the useful 80% in well under a day. That materially changes the calculus: the cost of not using it is low, and the cost of owning an archived dependency can exceed it.
• Roadmap / standards decision. This is a useful data point for a broader "third-party dependency policy" decision: do we permit archived packages, and what's our sunset rule? Given the package is archived, unmaintained since 2019, and scored 0.22 with 15 stars, the roadmap outcome should be "standardize on laminas/laminas-xml2json (the official successor) or native DOM, and do not add zendframework/* to new work."
• Framework-fit decision. Flag for stakeholders that this is not a Laravel package — no service provider, no facade, no config file, no Artisan commands, no published migrations. It is framework-agnostic glue. That's a plus for portability and a minus for anyone expecting Laravel-native ergonomics, testing helpers, or queue/HTTP integration.
• Legal/licensing posture. BSD-3-Clause is permissive and fork-friendly, which means the option to vendor and maintain a private fork remains open if a legacy integration truly depends on exact behavior.

When to Consider This Package

Consider it only when all of the following hold:

• You are already inside an existing Zend Framework 2/3 codebase pulling zendframework/* components and need behavioral parity with code that already ships — a stopgap, not a greenfield choice.
• The workload is an internal, non-customer-facing, offline batch conversion where a parse failure is recoverable and no PII/regulated data flows through the path.
• Your SCA/compliance tooling either isn't gating on "archived/no-security-response" packages, or you have an explicit, time-boxed exception on file.
• The XML is small enough to fit comfortably in memory — this is a DOM-based parse, so memory scales with document size.

Look elsewhere when any of the following is true:

• New Laravel application — this is the default case, and the answer is no. Use native SimpleXML/DOMDocument plus json_encode, or laminas/laminas-xml2json for API-compatible behavior with an active maintainer.
• PHP 8.1+ with a modernization mandate. A package last released in October 2019 has no security-response process. Archived status is precisely what dependency scanners escalate, and "we knowingly shipped an abandoned parser" is a hard conversation after an incident.
• You need fidelity. Naive XML→JSON loses or mangles attributes, namespaces, mixed content, repeated sibling elements, and CDATA unless carefully configured. If the contract matters, use sabre/xml or hand-written mapping — a generic converter turns schema ambiguity into silent data corruption.
• You need streaming. For large or unbounded feeds, XMLReader (pull-based) is the correct tool; DOM will OOM before it finishes.
• You need bidirectional or schema-aware work — validation against XSD, XSLT, or generating XML — this does one direction only.

How to Pitch It (Stakeholders)

To executives: Recommend against adopting this library. It is free and BSD-licensed, but it has been archived upstream since 2019, has negligible community adoption (15 stars, low health score), and receives no security patches. The financial exposure isn't license cost — it's supply-chain risk and the engineering time to rip it out later under pressure. The migration path to the maintained successor is a Composer swap plus a namespace change, so the cost of choosing correctly now is near zero.

To engineering: It's a ~1-class wrapper around DOMDocument exposing Xml2Json::fromXml(). No Laravel integration whatsoever — you'd wire it yourself. The successor project is laminas/laminas-xml2json (same API lineage, active maintenance); migrating is roughly a one-to-two-day task dominated by test updates, not code changes. If a legacy service already depends on it, contain it: pin the version, isolate it behind an internal XmlToArrayConverter interface, and add a golden-file test suite so the eventual swap is a dependency-injection change rather than a refactor.

Recommendation: Do not adopt for new work. Permit only as a documented, time-boxed exception inside existing Zend Framework code, with an owner and a dated removal ticket. Default new XML-ingestion work to native DOM/SimpleXML or laminas/laminas-xml2json.