Xml Core Laravel Package

Getting Started

• Install with composer require andrey-helldar/xml-core and note the resolved version — the last tagged release is 2.4.0 (Feb 2025) and the repository is archived. Pin it (^2.4 or exactly 2.4.0) and commit composer.lock.
• Reset your expectations before you look for integration scaffolding. This is a framework-agnostic XML utility, not a Laravel package: there is no service provider to auto-discover, no publishable config, no facade, no Blade views. If you ran php artisan vendor:publish expecting tags, you'll find none — that's by design, not a misconfiguration.
• Read in this order: the README usage block → src/ (it's small enough to read end to end in one sitting) → tests/. With an archived, lightly-starred package, the test suite is the real documentation; it shows the exact input/output shapes and the edge cases the maintainer cared about.
• Sanity-check your PHP constraint against the package's composer.json. If you're on Laravel 12 you're already at PHP 8.2+, so a conflict here is unusual; if composer require fails, it's almost certainly a transitive constraint, not this package.
• First use case: pick one direction of conversion in one place — either array → XML (building a payload for a partner/SOAP API, a sitemap, an export feed) or XML → array (ingesting a third-party feed). Put it behind a single service class, feed it a real sample payload, and confirm the output matches byte-for-byte expectations before you touch a second call site.
• Before you build anything load-bearing on it, do the ownership check: archived + 2 stars means you should be prepared to fork it into a path repository and maintain it yourself. Decide that up front rather than at the first bug.

Implementation Patterns

• Adapter, always. Wrap the package behind your own interface — e.g. App\Xml\XmlSerializer with toXml(array $data): string and toArray(string $xml): array — bound in a service provider. The package's concrete classes never appear in a controller, job, or model. This is the single highest-value pattern here because it makes the archive status irrelevant: swapping to spatie/array-to-xml or a hand-rolled DOMDocument later becomes a one-file change.
• Two-stage mapping. Don't hand the package an Eloquent model or a form request payload. Go model → plain array DTO → XML and, on the way in, XML → array → validated DTO. Keep the "array shape that the XML layer likes" (attributes, repeated nodes, CDATA) out of your domain layer.
• Own your configuration. Since there's no published config, create config/xml.php yourself for root element name, encoding, CDATA behaviour, and date formatting, and read it from your adapter. This gives you one place to change conventions and a clean seam for tests.
• Golden-file testing. XML assertions are brittle. Store representative fixtures in tests/fixtures/ and either compare normalized strings (strip insignificant whitespace) or — better — assert round-trips: build from a known array, parse it back, assert the array is unchanged. That catches escaping and empty-element regressions without pinning you to formatting details.
• Escaping is a convention, not an afterthought. Decide once whether rich text is emitted as CDATA or entity-escaped, and enforce it in the adapter. Mixed decisions across call sites are the most common source of "it works in staging" XML bugs.
• Queues and console commands are safe. It's pure PHP with no container or request state, so there's no long-running-worker hazard. Still prefer constructor injection of your adapter over static calls so jobs stay testable.
• Ecosystem composition. The author's other XML packages build on this one as their shared core. If you pull in a sibling package (feed/sitemap generators, etc.), resolve them together in one composer require and let Composer pick a compatible pair — a split resolution is the most likely source of an unsatisfiable graph or a runtime API mismatch.
• Fork-as-a-package when you need to patch. Add a repositories entry with {"type": "path", "url": "packages/xml-core"} and vendor the source. You get local fixes, code review, and a clear diff against upstream without waiting on an archived maintainer.
• Migration sequencing. If you're adopting it during a framework upgrade, bump/install the package on your current framework version first and run the suite; upgrade the framework on a separate branch. Coupling the two makes any failure ambiguous.

Gotchas and Tips

• Archived is the headline risk, not a footnote. No security patches, no PHP 8.4/9 guarantees, no deprecation policy. It's fine for a stable, small XML helper — it's not fine to put on a critical ingestion path with untrusted input unless you've reviewed the parsing code and are willing to own it.
• Don't let the changelog mislead you. 2.4.0 reads as "added Laravel 12 support," but the substantive content is a constraint relaxation plus a bot-authored LICENSE year bump. That does not make this a Laravel integration package; it confirms the release pipeline runs, nothing more.
• Array ↔ XML conversion is inherently lossy. Watch for: attributes vs. child elements, repeated siblings collapsing into one array key, empty elements becoming empty strings, mixed content, comments, and whitespace. Round-trip test every document shape you actually consume — not a generic sample.
• Namespaces are the number-one breakage. If the array conversion drops prefix declarations or reorders xmlns attributes, downstream SOAP/partner endpoints will reject the payload even though it "looks right." When namespaces matter, build the final string with DOMDocument and use the package only for the data-shape step.
• XXE / billion-laughs. If you parse untrusted XML, confirm external entity loading is disabled. If the package's parser doesn't expose that control, parse with DOMDocument/XMLReader configured safely first, or reject on <!DOCTYPE before handing it to the package.
• Memory on large feeds. Array conversion materializes the whole document. For multi-megabyte feeds, stream with XMLReader and use the package per-record instead of per-file.
• Encoding failures are silent-ish. A UTF-8 BOM or a stray non-UTF-8 byte typically surfaces as a malformed-output string rather than an exception. Set libxml_use_internal_errors(true), drain libxml_get_errors() in your adapter, and translate them into a domain exception so failures are debuggable.
• Debugging checklist, in order: dump the intermediate array before serialization (the array shape is almost always the bug, not the XML writer); check for BOM/encoding; verify the exact expected shape against the package's own tests; then compare escaped vs. CDATA output. If it fails only in production, check whether the payload contains characters your fixtures don't.
• Extension points to trust: your own adapter interface, your own config/xml.php, and fixtures. Avoid subclassing the package's concrete classes or reflecting into internals — there is no indication internals were ever treated as public API, and an archived project will never fix a subclassing break.
• Evaluate the alternatives honestly, early. For a single endpoint, DOMDocument/SimpleXML is zero dependencies; spatie/array-to-xml and symfony/serializer's XmlEncoder are actively maintained. Choose this package when you specifically value its small, focused API or its role as the base of the author's other XML packages — not by default.