Validation Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance. sulu/validation-bundle remains a Symfony bundle built for the Sulu CMS: bundle registration, DI service definitions, and event subscribers tied to Sulu's admin and content-schema lifecycle. Laravel has no bundle contract, so every integration point still needs a translation layer. What 0.3.0 does clarify is what the package is underneath — adding inline and other file $ref support plus caching of parsed schemas tells us the payload is JSON Schema documents, resolved and cached, not proprietary Sulu syntax. That is useful intelligence: it means the durable asset is a JSON Schema resolution/validation pipeline, and the Symfony wrapper is the only non-portable part.

Integration feasibility. Still low, but the release does not make it lower. Nothing in 0.3.0 touches PHP or Symfony version constraints — the changes are composer metadata (type correction), a parse cache, $ref handling, and test/documentation cleanup. Composer resolution against PHP 8.1+ and Symfony 6/7 will still fail before code executes, and the recommendation to spike rather than vendor stands. The one feasibility improvement is diagnostic: $ref support means the rule semantics are standard-adjacent, which raises confidence that a maintained validator can reproduce behavior, lowering the cost of the reimplement/adopt path.

Technical risk. Still high, with two refinements. First, the package shows continued but infrequent activity rather than a fully dead repo — the presence of named Sulu-org contributors on 0.3.0 means there is someone upstream, though it is not a support commitment and there is still no PHP 8 posture. Second, the new $ref support is a double-edged change: it broadens what the validator will parse (inline refs, external file refs), which increases the attack surface of code we would own if we vendored it — external file reference resolution is exactly the class of feature that produces SSRF and path-traversal findings in unmaintained libraries. Our empty telemetry set (no stars, no dependents, no install data) is unchanged, so there is still no community signal to lean on, and no evidence the 2017-era rules match current Sulu schema formats.

Key questions.

• Does the $ref support in 0.3.0 imply JSON Schema Draft compliance, and if so, which draft? That determines whether opis/json-schema or justinrainbow/json-schema is a faithful substitute.
• Are external file refs resolved from a trusted local path only, or can they be influenced by request input? If the latter, vendoring is off the table regardless of other factors.
• What is the concrete business requirement — validating JSON/XML content-type schemas, or validating authored content against those schemas?
• Does the requirement demand Sulu-compatible semantics, or would a standards-based JSON Schema validator satisfy it?
• Is a Sulu instance already in the estate that this must interoperate with, or is this a greenfield Laravel build?
• What is the acceptable remediation window for a CVE in a dependency whose last release is a feature-and-docs bump with no stated support policy?
• Would the parse-cache behavior in 0.3.0 be a functional requirement (i.e., are we validating large schema sets per request), and if so what invalidation guarantees do we need?

Integration Approach

Stack fit. Poor as a library; still useful as a specification, and now a slightly better one. Laravel's Validator, Form Requests, and rule objects cover conventional validation; opis/json-schema or justinrainbow/json-schema cover schema validation with active maintenance and built-in $ref resolution. The 0.3.0 caching feature is a reminder that schema parsing is expensive enough that the original authors added a cache — we get that behavior natively (or via a Laravel cache-backed resolver) from a maintained library, without inheriting the Symfony kernel.

Migration path. Unchanged: treat the bundle as a reference implementation, extract rules and error semantics, re-express as Laravel rule objects or a dedicated schema-validation service. 0.3.0 makes the extraction cheaper and more complete — the $ref handling and cache-invalidation semantics are now documented behaviors we can read and port rather than guess at. Vendoring the bundle itself remains non-viable.

Compatibility. Assume none out of the box. No PHP or Symfony version movement in this release, so the constraint conflicts identified previously are intact. Isolate evaluation in a throwaway branch or a separate service; never in the main dependency graph.

Sequencing.

1. Spike (1–2 days): confirm the schema-validation requirement, expected error output, and whether large/ref-linked schema sets are in scope (i.e., whether caching is a functional requirement).
2. Read 0.3.0's $ref and cache implementation as the behavioral spec; record which draft of JSON Schema it approximates and where it diverges.
3. Evaluate maintained alternatives against that spec with a fixture set of real schemas, including at least one with inline and external file refs.
4. Decide reimplement-vs-adopt-alternative; document the semantic mapping.
5. Build behind an interface (SchemaValidator), with cache invalidation as an explicit part of the contract rather than an implementation detail.
6. Only if a Sulu instance genuinely exists, integrate at the service boundary rather than in-process.

Operational Impact

Maintenance. Still total ownership transfer if vendored. The release slightly softens — but does not remove — the "abandoned" characterization: upstream is alive enough to merge features, but there is no release cadence, no support policy, and no compatibility statement for current PHP/Symfony. The effective posture remains "fork and maintain," now with modestly better odds of an upstream fix landing eventually, which is not something to plan capacity around.

Support. Still none in any contractual sense. There is an active contributor and an issue tracker that closed a feature request, so escalation is marginally less hopeless than a fully archived repo — but there is no SLA, no security contact documented, and incident response would still fall to internal staff reading the source. Governance finding stands.

Scaling. Validation remains CPU-bound and stateless, so horizontal scaling is straightforward. The 0.3.0 parse cache is a genuine performance improvement within the Symfony runtime — but it partially confirms our earlier concern: without caching, schema parsing per request is expensive enough to matter at volume. Any adopted alternative must have a comparable cache layer, and we should measure parse cost against our real schema set rather than assume it away. Running a second framework kernel in the request path remains a per-worker memory and bootstrap tax.

Failure modes.

• Composer resolution failure or forced version pins blocking Laravel upgrades (unchanged; no constraint work in 0.3.0).
• Silent semantic drift between the 2017-era rules and current Sulu schema formats, with no upstream commitment to reconcile.
• Unpatched vulnerability in schema parsing reachable from user input — now a broader surface, because $ref resolution can traverse inline and external file references. Path traversal and SSRF are the specific concerns.
• Cache staleness or incorrect invalidation if we ported the 0.3.0 cache semantics naively, producing validations against outdated schemas.
• Bus factor of one: no one on the team understands the rule set after the integrator leaves.
• Runtime fatals on PHP 8 due to removed functions and stricter type handling.

Ramp-up. Low for the concept, high for the code — unchanged. A developer learns Laravel validation or JSON Schema in days; reverse-engineering an unfamiliar Symfony bundle's intent takes far longer. The written rule specification remains the durable deliverable, and 0.3.0 gives us more raw material to write it from.

Recommendation. Do not adopt sulu/validation-bundle. Release 0.3.0 is a maintenance-and-features bump (parse caching, $ref support, composer metadata, docs) with no breaking changes, no deprecations, and — decisively — no movement on PHP or Symfony compatibility. It improves the package's value as a specification source and slightly improves our confidence that the underlying semantics are JSON Schema rather than Sulu-proprietary, which strengthens the case for a maintained validator behind a SchemaValidator interface. It does not change the integration verdict. Revisit only if a hard Sulu interoperability requirement emerges, and then integrate at the service boundary, not in-process.