Laravel Xml Laravel Package

Product Decisions This Supports

• Enterprise/partner integration scope. Whether to expose XML endpoints for customers who mandate it (banking, ERP, e-invoicing, government portals, SOAP-adjacent legacy systems). This package reframes the cost of that answer as "days, not weeks."
• Content distribution asks. RSS/Atom feeds and sitemaps — the recurring SEO/marketing request — become sprint-sized work rather than a project.
• Data interchange/exports. Generating XML for accounting, payroll, EDI, or regulatory submission, without inventing a bespoke serializer per consumer.
• Build vs. buy at the seam — and the honest answer is "neither." 88 stars, 0 dependents, MIT, single maintainer, active release cadence (v4.2.0, 2026). This is a thin convention layer over PHP's built-in XML extensions, not a platform. The real decision is adopt, fork, or write ~100 lines ourselves, and the deciding factor is convention consistency plus test helpers, not capability.
• Packaging/tiering. XML support can be an enterprise-tier entitlement or a flagged capability rather than core surface, because accepting XML bodies adds parsing attack surface (XXE, entity expansion) to every request it touches.
• Framework upgrade coupling (new in v4.2.0). The package now supports Laravel 13 only at the top end and has dropped Laravel 10/11 and PHP 8.1 as EOL. That means adopting it ties XML support to our Laravel upgrade cadence: on Laravel 10/11 we are frozen at v4.1.x with no further fixes, and once adopted, "stay on the package" becomes a (mild) argument for upgrading Laravel on the maintainer's schedule rather than ours. This is a scheduling constraint, not a capability one — budget it as such.
• Roadmap signal. Near-zero adoption means near-zero optionality value. Don't let XML become a strategic dependency; budget it as a compatibility shim. The upside: the v4.2.0 release shows the maintainer is actively doing hygiene work (CI modernization, EOL drops, Node 24), which is the best available proxy for "this will still build in 12 months."

When to Consider This Package

Consider it when:

• You are on Laravel 12/13 with PHP 8.2+ (the practical floor after v4.2.0). On Laravel 10/11, the only installable version is v4.1.x and it will not receive fixes — evaluate on that basis, or don't start.
• You need to return XML from Laravel controllers and want it to feel like response()->json() — one convention instead of N hand-rolled serializers.
• You need to accept XML request bodies from a partner and want parsing and validation wired into the request lifecycle rather than scattered in controllers.
• The XML surface is small and bounded: a handful of endpoints, one feed, one file export.
• The team is Laravel-fluent and would otherwise write inconsistent SimpleXML/DOM code with uneven escaping.
• You specifically value the XML response assertions for tests — structure assertions often justify the dependency more than serialization does.

Look elsewhere when:

• SOAP is involved — use a WSDL-driven client (e.g. phpro/soap-client) rather than hand-rolling XML over HTTP.
• You need XSD validation, XSLT, or namespace-heavy documents — go direct to ext-dom/libxml where you control parsing options.
• Payloads are large or throughput matters — streaming (XMLReader/XMLWriter) beats building a DOM in memory.
• Security posture forbids a single-maintainer dependency in the request path.
• The "XML need" is really just sitemaps or feeds — a purpose-built package is the better fit.
• You require vendor support or SLAs — there's no commercial backing here.
• You are pinned to Laravel 10/11 for the foreseeable future and want a dependency that tracks your upgrade window rather than the framework's release train.

Adoption criteria to hold yourself to: pin the version (and record the v4.2.0 breaking floor — Laravel 12+, PHP 8.2+ — in the ADR), wrap it behind your own request/response helpers so it's swappable, and set libxml options explicitly (no external entity loading, no network access). Treat the 4.x line as fast-moving: minor bumps can drop framework versions, so read changelogs before composer update in CI. With 0 dependents and 88 stars, pre-commit to a fork path — the code is small enough to vendor in hours if maintenance lapses.

How to Pitch It (Stakeholders)

Executives: A small, MIT-licensed Laravel add-on that lets us speak XML — the format several enterprise customers, regulators, and legacy systems still require. It's a few days of integration, not a platform commitment, and it unblocks a category of deals and compliance asks we currently quote as custom work. License cost is zero; the real costs are a security review and a maintenance hedge, both of which we've scoped. The latest release (v4.2.0) is maintenance-only — CI modernization and support-matrix housekeeping, no new features — which is a positive signal about the maintainer's engagement and confirms there's no hidden platform we're buying into. The one thing to know: it now requires Laravel 12+ and PHP 8.2+, so it only lands after our framework upgrade, and it should be sequenced accordingly rather than promised to a customer ahead of that work.

Engineering: A thin convention layer over PHP's built-in XML extensions — response helpers, request-parsing middleware, and test assertions. It standardizes how we emit and accept XML so we stop writing one-off serializers. It does not give us XSD validation, XSLT, or streaming; if we need those, we go to ext-dom directly. v4.2.0 is a breaking release on the support matrix, not the API: Laravel 10/11 and PHP 8.1 are dropped, Laravel 13 is added, CI actions and the Node runtime are bumped. No code changes expected on our side, but Composer will refuse the upgrade if we're below the floor, and v4.1.x is now a dead branch. Risks are the standard XML ones (XXE, billion-laughs), so we pin the version, wrap it in our own helpers, and harden libxml at the boundary.

Recommendation: Adopt narrowly, behind a feature flag, for one named use case — then reassess breadth after the security review. Sequence it behind the Laravel 12/13 upgrade rather than alongside it, and keep it off the critical path. If the maintainer goes quiet, our fork cost is measured in hours, not weeks.