Xmlvalid Laravel Laravel Package

Product Decisions This Supports

• Feature delivery: user-facing XML validation. This package lets a Laravel product validate XML documents (invoices, e-invoices/UBL, EDI payloads, regulatory filings, import files) and surface structured errors. The v1.2.0 change matters here: each error now carries a path identifying where the business rule fired, so the product can render "line 4, element cbc:InvoiceTypeCode violates rule X" instead of a generic "invalid document" — the difference between a support ticket and a self-service fix.
• Build vs. buy. The decision this most directly informs is whether to build an XML validation engine in-house (schema compilation, rule evaluation, error localization, engine selection) versus composing this package. The release reinforces the buy/compose side: the maintainers are investing in API fidelity of the test double, which is a maturity signal that the underlying engine contract is stabilizing rather than churning.
• Roadmap sequencing for compliance work. Because engine and sha256 are now part of the result contract, the roadmap can plan features that depend on provenance and reproducibility — audit trails ("which engine validated this document, and is this the exact artifact we validated?"), re-validation on engine upgrades, and deduplication/caching keyed on document hash. Those are expensive to retrofit; plan them now if they're on the horizon.
• Confidence in CI as a delivery lever. The headline of v1.2.0 is a testing improvement, not a runtime feature. XmlvalidFake now answers as the real API does, so tests can assert on path, sha256, and engine without network calls or fixture drift. That shortens the feedback loop on validation-dependent features and removes a class of "passes in CI, fails in staging" defects. Worth weighting if validation logic sits on a critical path.
• Use cases to prioritize: document ingestion with human remediation, e-invoicing/Peppol-style regulatory conformance, pre-submission checks before sending payloads to a counterparty or authority, and content pipelines where malformed XML must be rejected before it reaches downstream systems.

When to Consider This Package

Adopt when:

• The product is a Laravel/PHP application and XML validation is a product feature (users see and act on errors), not an internal sanity check.
• You need business-rule errors localized to a path, not just XSD conformance — the release's emphasis on path and rule-level reporting suggests this is the package's center of gravity.
• You want tests that exercise the real response contract. The new fake returns path, sha256, and engine, so validation-dependent tests can assert on the same fields production reads. This is a strong reason to prefer it over hand-rolled HTTP mocks.
• You need provenance — recording which engine validated a document and the document hash — for audit, traceability, or reproducibility requirements.
• You are comfortable taking a dependency on xmlvalid/xmlvalid-php 1.2+; v1.2.0 of this package requires it, since the result models are what actually read the new fields.

Look elsewhere when:

• You need XSD/RelaxNG schema validation only. PHP's native DOMDocument::schemaValidate is free, synchronous, and dependency-free. This package is worth its weight only when business rules, structured error paths, or engine metadata are in scope.
• The service is not Laravel, or is a polyglot/worker-based architecture where a PHP wrapper adds a hop without adding value.
• Throughput and latency dominate. Validate the execution model (sync vs. queued, batch support, timeouts, retry semantics) and the cost profile of the upstream engine before committing; a request-path validator is a different product decision from an async pipeline validator.
• You need XML generation or repair as well as validation — this is a validator, and pairing it with a generator is a separate evaluation.
• The rule sets you care about aren't covered by the upstream engine. Confirm coverage against your actual target standard (and version) with a spike on real documents, not sample fixtures.
• Your team cannot absorb transitive version coupling. v1.2.0 pins a minimum upstream version; if you have other dependencies constrained to xmlvalid-php <1.2, resolve that before adopting.

Migration note for the upgrade: v1.2.0 is additive at the contract level, so it should be a low-risk bump — but any test that asserted on the old fake's response shape (missing path, sha256, engine) is now asserting against a stricter object and may need its expectations updated. Budget a short pass over validation tests; treat the fake's response shape as a contract you own going forward.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship XML validation as a real product capability — showing users exactly which rule failed and where — without building and maintaining a validation engine ourselves. The 1.2.0 release is a maturity signal: the vendor has made their testing layer match their production API, which means our automated tests now check the same fields our customers will see. That reduces the risk and cost of compliance-adjacent features (e-invoicing, document ingestion, regulatory submissions) and lets us add audit-grade traceability — which engine validated a document, and a hash of the exact document — when regulation or enterprise buyers ask for it. The main thing to manage is a dependency upgrade, not a re-architecture.

For engineering (the short version):

• Thin Laravel wrapper over xmlvalid/xmlvalid-php; validation results are structured objects, and errors are now path-addressable.
• v1.2.0 makes XmlvalidFake behave like the live API: path per error, sha256 and engine on the result. Use it in feature tests instead of HTTP fakes — assertions on error location and provenance now work offline.
• Requires xmlvalid/xmlvalid-php ^1.2 — the models, not the wrapper, read the new fields. Bump both together and check for conflicting constraints.
• Treat the fake's response shape as a test contract: audit existing validation tests for assertions built on the older, thinner payload.
• Design implication: sha256 and engine are cheap to persist now and awkward to backfill later — decide early whether results are stored for audit and caching.