Json Schema Bundle Laravel Package

Product Decisions This Supports

• Contract-first API delivery. JSON Schema validation is a product capability, not just a library choice: it lets you publish a machine-readable contract for request/response payloads so frontend, mobile, and partner teams can build in parallel against a spec instead of prose docs.
• Build vs. buy for validation. v1.0.0 does not change the underlying economics: this is still a thin Symfony bundle wiring layer over justinrainbow/json-schema, contributing container configuration rather than validation logic. The real build-vs-buy decision remains whether to adopt a JSON Schema validator at all.
• Where schema validation earns its keep as a feature: third-party webhook/payload ingestion (validate before persisting), public API input validation with consumer-friendly error messages, config-as-data (tenant settings, feature flag payloads, workflow definitions), event/message schema enforcement across services, and API versioning/deprecation gates.
• Buying vs. building the integration. For a Laravel product, the "integration" is a ~100-line service provider plus a custom validation rule. That is a small, low-risk build, which materially weakens the case for adopting any third-party glue package — and v1.0.0 adds no Laravel-facing surface.
• Maintenance signal improved, but only marginally. v1.0.0 (dependency refresh, MIT license added, tests for obsolete PHP/Symfony versions disabled) is a genuine positive: there is now a license, a release, and a maintainer touching the code. It is still a single-maintainer artifact with no dependents and no articulated support policy. A roadmap decision to depend on it remains a decision to own it.
• Breaking change worth flagging to anyone already pinned. The switch to vendor-based service and parameter names is a breaking change for existing Symfony consumers — DI service IDs and parameter keys they may reference in config will no longer resolve. This is release hygiene for a bundle nobody should be adopting fresh, but it confirms the package is not a stable contract you can lean on.
• Not a fit for the stated stack. This is a Symfony bundle, not a Laravel package. Its value proposition (bundle registration, DI wiring, named services) does not exist in Laravel's service container, so the product decision for a Laravel roadmap is still a clear "no" on this artifact regardless of the release.

When to Consider This Package

Consider it only if all of the following hold:

• You maintain a Symfony application (this release targets non-obsolete Symfony versions, so a maintained 5.x/6.x/7.x line is now plausible — verify against your constraint) that already depends on justinrainbow/json-schema.
• You want bundle-style DI wiring for validators and are unwilling to write a short service definition yourself.
• You are adopting it fresh or are prepared to migrate service IDs and parameter names per the v1.0.0 vendor-prefix change.
• You have verified Composer resolution and CI against your PHP version — the release notes describe dropping obsolete test targets, not a documented support matrix, so compatibility claims should be tested rather than assumed.
• You accept single-maintainer risk: no dependents, no community patch flow, and no stated security or release cadence, even with an MIT license now in place.

Look elsewhere if any of these are true — i.e., almost always in our context:

• You are on Laravel or any non-Symfony framework. Use justinrainbow/json-schema or opis/json-schema directly and wrap it in a service provider and a Validator rule. You get the same capability with a dependency you control and a modern support story.
• You need schema draft support beyond draft-04. opis/json-schema covers newer drafts (2019-09, 2020-12) and produces better error output. v1.0.0 refreshed dependencies but did not change the validator's draft ceiling.
• You need a documented support policy, CVE response, or a public roadmap. A license and a version bump are not a maintenance commitment; there is still no dependents base to absorb bugs and no Stack Overflow corpus.
• You are mid-migration on an existing Symfony install. The service/parameter renaming is a breaking change; budget for it explicitly rather than assuming a patch-level upgrade.

How to Pitch It (Stakeholders)

Executives: JSON Schema validation remains a worthwhile capability — it hardens API surfaces against malformed third-party payloads and cuts defensive validation code. The package itself just shipped v1.0.0: dependency refresh, an MIT license, and a cleanup of obsolete test targets. That is a modestly healthier project than the abandoned 2016 artifact we assessed, but it is still a thin Symfony wiring layer with a single maintainer and no dependents, and it delivers no capability we cannot get from the underlying library in a day of engineering work. Recommendation: do not adopt; the release improves the reference implementation, not our build-vs-buy math. The capability is approved for a small spike; the dependency is not.

Engineering: The bundle is a DI wrapper around justinrainbow/json-schema and remains structurally inapplicable to Laravel. v1.0.0's substantive change — vendor-prefixed service and parameter names — is a breaking change for existing Symfony consumers and irrelevant to us either way; the dependency refresh and MIT license are welcome but do not establish a support commitment, and the "disabled obsolete PHP/Symfony tests" note means compatibility should be verified against our runtime, not assumed. Instead, spend one to two days adding opis/json-schema (preferred, modern draft support) or justinrainbow/json-schema (if we need draft-04 parity with an existing spec) behind a JsonSchemaRule validation rule and a small service provider. This keeps the contract-validation capability, keeps the dependency maintained, and keeps the integration — the only part this package actually provides — under our control.

Decision summary: Capability: yes, on the roadmap (contract validation for API inputs and webhook ingestion). Package: no — still low opportunity for a Laravel roadmap, wrong framework, thin wrapper, single maintainer; v1.0.0 raises project health from "abandoned" to "lightly maintained" without changing the recommendation. Cost to replicate: ~1–2 engineer-days. Watch item: if we ever acquire a Symfony service, re-evaluate on that stack rather than this one.