Pretty Xml Laravel Package

Product Decisions This Supports

• Feature delivery for XML-emitting surfaces. Anything that ships XML to a consumer — SOAP/legacy ERP integrations, partner feeds, invoice/e-invoice exports, sitemaps, bank or EDI payloads, Office/XML document generation — needs a consistent answer for "how is this formatted?" This package answers it in one line: format() for humans, minify() for the wire.
• Build vs. buy (and the honest middle option). The decision is not "buy a platform," it's "do we own 150 lines of indentation logic forever?" The package exposes two behavior methods (format, minify) plus two configuration setters (setIndentSize, setIndentCharacter) and has no framework coupling. Frame the options as: (a) adopt via Composer, (b) vendor/copy the formatter under MIT, (c) keep hand-rolling DOMDocument::saveXML() plus regex fixups. Option (c) is the only one that reliably costs more than it saves.
• Configuration over code branches. The local/staging vs. production formatting decision should be a single config flag ("pretty in debug, minified in prod"), not ad-hoc if (app()->isLocal()) scattered across controllers. This package makes that a one-line switch, which is a product-quality decision about predictable output.
• Developer experience and support tooling. Debug endpoints, admin XML viewers, log/response inspection in Tinker, and customer-support reproduction of a broken partner payload all depend on readable XML. This is an enabler for DX and support workstreams — it should be scoped as plumbing, not as a roadmap line item with its own business case.
• Test determinism. Because 3.1.1 makes formatting converge (format-twice == format-once), formatting can safely live in stacked middleware, queued post-processing, or cached-then-reformatted payloads. That converts a latent flaky-output risk into a locked-in invariant, which is a genuine (if unglamorous) reliability decision.
• Explicit non-goals. This does not parse, validate against XSD, transform (XSLT), or canonicalize. If a roadmap item implies any of those, this package is a formatting detail inside a larger decision, not the decision itself.

When to Consider This Package

Adopt when most of the following hold:

• You already emit or ingest XML and the current formatting is manual, inconsistent, or copy-pasted across controllers.
• You need configurable indentation — this is the package's stated reason to exist, since DOMDocument hardcodes a 2-space indent and offers no knob. If 2 spaces is fine, the built-in is usually enough.
• You want minification with optional comment preservation for production responses, in the same dependency as prettification.
• You're on PHP 8.1+/Laravel 10–11, and adding a zero-dependency, MIT-licensed Composer package is a routine, low-ceremony action.
• The formatting step sits off the hot path, or payloads are small (rule of thumb: validate anything over ~1MB in staging before committing).

Look elsewhere or write it yourself when:

• Whitespace-sensitive payloads are in scope. Signed XML (XMLDSig), canonicalization, mixed-content documents where indentation is semantically meaningful, or strict partner schemas that dictate byte layout. Pretty-printing changes bytes; that's a contract breach, not a formatting preference. Default to minify() — or no touch at all — for these.
• The product is JSON-only. Adding a dependency with no caller is pure supply-chain surface for zero value.
• Supply-chain review is strict. 22 stars, 0 dependents, a single primary maintainer. That's not disqualifying for a formatting utility, but under a vendor-approval regime the pragmatic answer is to vendor the file (MIT permits it) rather than take it as a runtime dependency on a critical path.
• You need parsing, validation, XPath, or transformation. Use DOMDocument, SimpleXMLElement, or a dedicated XML library; this one is a formatter, and it requires well-formed input.
• Full round-trip fidelity matters — comments, processing instructions, and doctype handling should be verified against your representative payloads before adoption, not assumed.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed utility that makes our XML responses consistent and readable in lower environments and smaller on the wire in production. No infrastructure change, no vendor contract, no lock-in — the entire public surface is a couple of methods, so if it ever becomes a problem we replace it in under a day. The business value is indirect but real: less time spent debugging partner integrations and support tickets, and smaller payloads for XML-consuming clients.

To engineering: Stateless, side-effect-free, PHP-core-only, trivially testable. Pin ^3.1.1 — that release fixes a text-node convergence bug that made repeated formatting drift, which matters the moment formatting lives in middleware that might run twice. Wire it as a single FormatXmlResponse middleware gated on Content-Type: application/xml, guard re-entry with a response flag anyway, keep prettification to local/staging/debug routes, and add two cheap tests: assertXmlStringEqualsXmlString() on a representative fixture, and an explicit format-twice-equals-format-once assertion. Document the one-line rule in the contributing guide so nobody reintroduces a DOMDocument indent hack.

On risk, stated plainly rather than buried: small project, low adoption, one maintainer, patch-level releases with narrow scoped fixes. That profile is acceptable for a leaf-node formatting helper and unacceptable on a critical path for signed or regulated documents — so we scope it accordingly. Mitigations are cheap: vendor or fork under MIT if maintenance lapses, fall back to DOMDocument if anything misbehaves, and cache minified output where the same XML is served repeatedly. The failure mode we care about is silent output corruption, which is why the XML-equality assertion and payload review are part of the adoption, not a later hardening task.