- How do I install and use mtownsend/response-xml in a Laravel app?
- Install it with composer require mtownsend/response-xml. On modern Laravel the service provider is auto-discovered, so no manual registration is needed. You then return response()->xml($data) from a controller or route just like you would return response()->json($data). An optional config file can be published if you want to change the default root element name.
- Which Laravel and PHP versions does response-xml support?
- The package is a thin extension of Laravel's ResponseFactory contract and is auto-discovered on modern Laravel releases, but the exact supported range is defined in its composer.json constraints rather than the README. Check the CI matrix in the repository to confirm the current Laravel LTS and your pinned PHP version are explicitly covered. The safest verification is a throwaway branch that resolves the dependency against your actual composer.lock and runs your test suite.
- How do I change the root XML element name or the encoding?
- You can publish the package config and set the default root node name used when serializing responses. Custom root nodes, headers, and encoding can also be passed per response through the fluent xml() helper. This lets different endpoints emit different root elements without touching global configuration.
- Does response-xml work with Eloquent models, collections, and paginators?
- Yes, the package converts Eloquent models, collections, plain arrays, and paginators into XML. Internally it normalizes these structures before serializing them, so you can pass the same payload you would normally hand to response()->json(). Because array-to-XML conversion is lossy, verify the resulting shape against the schema your consumer expects.
- Can I set custom XML headers and a content type on the response?
- Yes. The helper sets an XML content type automatically and also accepts additional headers, so you can add things like caching or custom content-type variants. This keeps XML responses consistent with the rest of your Laravel response layer.
- How are numeric arrays, empty arrays, nulls, and booleans serialized to XML?
- These conversions follow the package's own private conventions rather than a public specification, so the exact output for repeated siblings, numeric keys, empty arrays, nulls, and booleans should be confirmed empirically. Array-to-XML is inherently lossy, and mixed content, attributes, and namespaces are not guaranteed behaviors. Write golden-file tests for every payload shape your consumers depend on before trusting the output in production.
- Will response-xml conflict with Laravel's normal JSON or view responses?
- The package rebinds Laravel's ResponseFactory contract to a subclass that adds one xml() method, and JSON and view responses are untouched by that substitution. The binding is process-global, however, so any code in your stack that type-hints or resolves the ResponseFactory contract will receive the subclass. Add a smoke test proving existing JSON and Blade responses still behave correctly after installation.
- Is response-xml safe for production, especially around XML escaping?
- The write path is low risk provided values are properly escaped, which you should confirm rather than assume. XXE is a read-path concern and is out of scope for a response serializer. Include adversarial payloads such as ampersands, angle brackets, quotes, and unicode in your contract tests before shipping to real consumers.
- Does response-xml support XML attributes, namespaces, or CDATA sections?
- The package is focused on converting nested arrays and models into nested XML elements, and attributes, namespaces, and CDATA are not documented guarantees. If your consumer's schema requires them, test the exact output first or use a dedicated converter such as spatie/array-to-xml that exposes those features explicitly. For schemas with attributes or mixed content, wrapping the serializer behind your own adapter is the safer design.
- Is mtownsend/response-xml actively maintained, and what are the alternatives?
- It is an MIT-licensed package from a single maintainer with a small star count and essentially no dependents, which means edge cases have been exercised by very few users beyond the author. Recent releases are a positive signal but not a substitute for adoption, so plan a fork-and-vendor escape hatch. Alternatives include spatie/array-to-xml with a custom response macro, or hand-rolling a small XML responder in your own codebase, which is feasible given the package is only a few hundred lines.