Validation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for schema validation in a CMS/admin context. This bundle is a narrow, single-purpose artifact: it wires schema validation into Sulu's bundle system. It's useful mainly as prior art when scoping "do we write our own validation layer for structured content, or lean on Symfony Validator / a JSON Schema library?" The existence of a first-party-style bundle tells you Sulu treats content schema integrity as a platform concern — but the 2017 archive date tells you they've since moved that responsibility elsewhere (Sulu core, Symfony Validator, or the content-type metadata layer).
• Use-case scoping. Realistic scenarios it maps to: validating structured content types before persistence, validating imported/ETL payloads against a declared schema, guarding template/schema migrations, and enforcing API contracts for headless delivery. Each of these is better served today by a maintained JSON Schema validator or Symfony constraints — but the use-case list is still the right starting point for a validation design doc.
• Roadmap signal, not roadmap input. With 0 stars, 0 dependents, no releases since April 2017, and an archived repo, this should not appear as a dependency in any forward-looking roadmap. Its value is entirely informational: it confirms the problem space exists and shows one historical implementation shape.
• Legacy-estate triage. If you have a Sulu 1.x application pinned to this bundle, the decision it supports is a migration decision: quantify the blast radius of replacing it, and schedule that replacement rather than continuing to inherit an unpatched dependency.
• It does not support a go/no-go decision. There is no adoption case to evaluate here. Treat it as a reference implementation you may read for 30 minutes, not a candidate for a spike.

When to Consider This Package

Consider it only under these narrow conditions:

• You are maintaining an existing Sulu 1.x codebase that already depends on it, and you need to understand its behavior before replacing or removing it. In that case, read the source, don't add it anywhere new.
• You are designing a validation layer and want a concrete, small example of how schema validation was bound into a Symfony/Sulu bundle structure circa 2017 — as a pattern reference, not as code you ship.
• You need archaeological context on why a Sulu project's validation behaves the way it does.

Look elsewhere in essentially every other case:

• No maintenance and no security path. Archived, last release 2017-04-07. No CVE response, no PHP 8.x or Symfony 5/6/7 compatibility guarantees. That alone disqualifies it for new or production-adjacent work.
• No ecosystem validation. Zero stars and zero dependents means no field testing, no issue history to learn from, and no community to lean on — you'd be the only operator.
• Mature alternatives exist and are cheap. Symfony Validator for object/constraint validation, opis/json-schema or justinrainbow/json-schema for document schema validation, and the current Sulu core for CMS-specific content validation. All are maintained, documented, and hire-for.
• Opportunity score is 14.7 and the composite score is 0.57. That is a quantitative restatement of the same conclusion: low leverage, low momentum, high replacement availability.

How to Pitch It (Stakeholders)

One-line summary: An archived 2017 Sulu bundle for schema validation — useful as a design reference, not viable as a dependency.

For executives: We evaluated sulu/validation-bundle and are recommending against adoption. It has had no release since 2017, is formally archived upstream, and has no dependents or community. Adopting it would create an unpatched dependency in a security-sensitive area (input validation) with no vendor or community recourse. The underlying need — validating structured content against a schema — is fully served by maintained Symfony and JSON Schema tooling at effectively zero incremental cost. Decision: no adoption; if we have legacy Sulu code using it, we fund a scoped replacement.

For engineering: Don't add this to anything. If you're on a legacy Sulu 1.x app that already uses it, the work item is "identify call sites, replace with Symfony Validator constraints or a maintained JSON Schema validator, delete the dependency," budgeted as small-to-medium based on how deeply it's wired into content-type handling. If you're designing validation fresh, use Symfony Validator for domain objects and opis/json-schema for document-shaped payloads; both give you PHP 8 compatibility, active maintenance, and a hiring pool. The only thing worth taking from this bundle is a skim of its structure as a worked example of binding validation into a bundle — thirty minutes, not a spike.