Xml To Array Laravel Package

Technical Evaluation

Architecture fit

• Thin, stateless adapter over PHP's ext-simplexml. No service container requirements, no event/queue/cache coupling, no persistence, no global state. It can live at the edge of an ingestion pipeline and be discarded without architectural debt.
• Appropriate for: webhook/partner payload parsing, legacy SOAP or REST feed ingestion, config/seed file loading, one-shot imports, admin-uploaded XML previews.
• Inappropriate for: streaming or very large documents (whole document is materialized in memory), XSD-validated ingestion, XSLT transformation, mixed-content document models, or anything where element order and text-node interleaving are semantically meaningful.
• Because it returns an untyped array, it is a parsing utility, not a modeling utility. It should feed a mapper/DTO layer, never your domain objects directly.

Integration feasibility

• composer require mtownsend/xml-to-array; Laravel package auto-discovery handles the service provider. Plain-PHP usage via a static call works without the framework.
• Only runtime requirement is ext-simplexml, which ships enabled in virtually all PHP builds. No database, no queue, no published config required.
• MIT license removes legal friction; no attribution burden beyond the license file.
• Realistic effort: under a day including tests, assuming representative sample payloads are available.

Technical risk

• Array-shape instability is the dominant risk. The classic XML→array footgun: an element with one child yields a scalar, the same element with two children yields an array. Consumers written against one shape break on the other. This is inherent to the approach, not a bug in this package, but it is the failure you will actually hit in production.
• Lossy conventions. Attributes and text are mapped to reserved keys (@attributes, @value, and similar). A real XML element literally named @attributes (rare but legal) collides. Namespace handling is partial and easy to get wrong.
• Security posture must be verified, not assumed. Confirm the implementation does not pass LIBXML_NOENT and does pass LIBXML_NONET. Modern libxml disables network entity loading by default, but "default" is not a control — read the code. Entity-expansion ("billion laughs") protection depends on libxml_disable_entity_loader/libxml version behavior, so cap input size upstream regardless.
• Error semantics. Verify what is thrown on malformed XML. A generic Exception rather than a typed exception means callers must catch narrowly or wrap defensively.
• Empty/absent ambiguity: <a/>, <a></a>, and a missing <a> are not reliably distinguishable in the resulting array. If your downstream logic cares, this package is the wrong layer.
• Maintenance concentration. 116 stars, zero dependents, effectively a single-maintainer package. The code is small enough to fork, which is the real mitigation.

Key questions

1. Is LIBXML_NONET set and LIBXML_NOENT absent? Can libxml options be passed through by the caller?
2. Are single-vs-multiple-child array shapes normalized or left to PHP's natural behavior?
3. Is the @attributes key name configurable, and is there a documented escaping rule for collisions?
4. How is mixed content (text interleaved with child elements) represented — dropped, concatenated, or preserved?
5. What is the declared support matrix (PHP versions, Laravel/illuminate/support constraints) and does it match our app?
6. What exception type is raised on invalid XML, and are libxml warnings surfaced or suppressed?
7. Is there a documented policy for xsi:nil, CDATA sections, and repeated siblings with differing attributes?
8. What is the succession plan — is the repository active enough that a fork is unnecessary for the next 24 months?

Integration Approach

Stack fit

• Laravel 8–12 / PHP 8.1+ fits naturally, with or without the facade. Also usable in any Composer project, including legacy non-framework code being incrementally modernized.
• Pairs cleanly with HTTP client ingestion, queued jobs, and filesystem/object-storage reads. It composes badly with anything expecting a schema-stable contract downstream — so pair it with a hydrator (spatie/laravel-data, Symfony Serializer, or a hand-written mapper) that owns shape normalization.
• Do not pair it with a validator that expects the array shape to be authoritative; validate the XML (XSD or manual) before conversion, not after.

Migration path

• Greenfield: define an internal XmlParser interface with one method returning a typed DTO. Implement it with this package. No call site ever references the package by name. This is the whole migration strategy and it costs an hour.
• Brownfield: wrap existing simplexml_load_string call sites behind the same interface, run both implementations against a golden-file corpus, diff the outputs, cut over call site by call site. Expect diffs in attribute representation and single-child shapes; resolve them in the mapper, not by patching the package.
• Exit: if the package is abandoned, the wrapper is reimplementable in well under 100 lines using DOMDocument or XMLReader. Budget the fork, not a rewrite.

Compatibility

• Read composer.json constraints against your matrix before merging. The most common integration failure here is an illuminate/support version pin that lags your framework major by one release.
• Check PHP 8.3/8.4 deprecation cleanliness (implicit nullable parameters, dynamic properties). Run your CI matrix against the package's tests, not just your own.
• Confirm the release cadence aligns with your upgrade cadence — a package that lags framework majors by six months becomes a blocker at every Laravel upgrade.

Sequencing

1. Collect 10–20 real payloads (including malformed, empty, namespaced, and attribute-heavy cases). Do not evaluate on the README example.
2. Security review of libxml flags and input-size limits. Gate on this.
3. Build the wrapper interface plus golden-file tests that pin the array shape explicitly.
4. Integrate one low-risk consumer behind a feature flag; compare output against the incumbent path in production shadow mode.
5. Expand to remaining consumers only after shape normalization is proven in the mapper.
6. Document the array convention internally so the next engineer does not rediscover the single-child behavior in production.

Operational Impact

Maintenance

• Surface area is a few hundred lines; the code is readable in one sitting. Maintenance burden is near zero while maintained and near zero if forked — this is the package's genuine strength.
• The real maintenance question is upstream liveness, not code complexity. Track release cadence and framework-major support. If it goes quiet, fork under your org, keep the MIT header, and move on.
• Budget roughly half an engineer-day per year for upgrades and drift checks. Zero dependents means no transitive supply-chain exposure — a security positive — but also no community pressure fixing edge cases you will encounter alone.

Support

• GitHub issues only; no commercial support, no SLA. Your wrapper's test suite is the actual support contract.
• Assign a named internal owner even though the package is trivial. Unowned dependencies are how forks get discovered late.

Scaling

• Fine for request-scoped documents in the KB to low-MB range. Memory consumption is roughly 5–10× the raw XML size due to DOM overhead plus the array copy — plan accordingly and cap upload/payload size at the ingress layer.
• Not appropriate for multi-MB-plus or high-throughput parsing. For those, use XMLReader streaming or a SAX approach; this package has no streaming mode.
• Stateless with no shared resources, so horizontal scaling is trivial — no cache coherency, connection pool, or concurrency concerns.

Failure modes

• Malformed XML throwing a generic exception that escapes a broad catch and surfaces as a 500.
• Silent shape drift when a partner starts sending two <item> elements instead of one — the highest-probability production incident with this package.
• Attribute/element name collisions corrupting parsed data without error.
• Partial namespace handling producing keys that look correct and are not.
• Memory exhaustion on an unexpectedly large document (a decompression-bomb style payload is a plausible vector).
• libxml warnings leaking to logs or the response if the error handler is not scoped.
• Empty-element/absent-element conflation producing false negatives in validation logic.
• XXE, if libxml options are ever relaxed by a well-meaning contributor.

Ramp-up

• Any PHP developer is productive in under 30 minutes: one facade call, a documented return shape.
• The actual learning curve is not the API, it is the array convention's edge cases (attributes, namespaces, single-child collapse, empty elements). A one-page internal convention document plus the golden-file corpus collapses this to an afternoon and prevents the recurring "why is this sometimes a string" ticket.
• Onboarding cost is low enough that the package should not appear in architecture review discussions — treat it as a replaceable implementation detail, adopted behind an interface, with no platform commitment implied.