Json Schema Bundle Laravel Package

Product Decisions This Supports

• Contract-first API design. The package's core idea — validate JSON payloads against a schema at the boundary — is a roadmap decision, not a library decision. It informs whether schemas become the single source of truth for request validation, webhook payloads, and event contracts across services.
• Build vs. buy for integration glue. This bundle is thin: it wires Justin Rainbow's json-schema library into the Symfony DI container, adds a validator service and exception handling. That is roughly a day or two of engineering, not a platform capability. The PM decision is therefore about the engine (opis/json-schema vs. justinrainbow) and the framework version — the bundle itself is incidental.
• Use cases it validates the need for: request-body validation on API endpoints, verification of inbound webhooks from third parties, schema-checking of config files at deploy time, and validating JSON fixtures/seeds in CI. If two or more of these are on the roadmap, a schema layer is justified — but this package is not the recommended implementation.
• Adoption signal check. 6 stars, 0 dependents, and a viability score of 0.15 mean there is no de facto standard here and no community to absorb maintenance. The high opportunity score (0.8) reflects an unmet need for schema-driven validation, not confidence in this specific artifact. Do not read the opportunity score as a buy signal.
• Technical-debt forecasting. Adopting a Symfony2-era bundle today creates a scheduled rewrite. The decision record should note that rebuilding the glue now is cheaper than removing the dependency after it is embedded in request pipelines.

When to Consider This Package

• Only in a legacy Symfony 2.x/3.x application that already depends on justinrainbow/json-schema, where a small bundle avoids writing new glue and the app is already in a frozen maintenance window.
• Internal tools and prototypes where the team explicitly accepts an unmaintained dependency, pins versions, and has no production security surface.
• As a reference implementation, not a dependency. Read it to understand wiring patterns — schema resolution, validator service registration, error-to-exception mapping — then copy the pattern into a maintained internal adapter.
• Look elsewhere when: you are on Symfony 4.4+ (use the built-in Json constraint or a request listener), you need performance or draft 2019-09/2020-12 support (use opis/json-schema), you are validating against OpenAPI documents, or the validation sits on a security-sensitive path. EOL Symfony 2 has no CVE coverage, and an unmaintained transitive dependency is a supply-chain liability that will surface in any serious review.

How to Pitch It (Stakeholders)

• Executives: this is not a strategic dependency and should not enter the architecture. It is a small accelerator for a narrow legacy case. The decision worth funding is "schema-as-contract" for our APIs — which we should build on a maintained library, not on a Symfony2-era bundle.
• Engineering: treat it as a design reference. A request listener plus a validator service around opis/json-schema (or Symfony's native Json constraint) takes comparable effort, is maintained, and supports modern JSON Schema drafts. Same outcome, no migration debt.
• Ask: approve schema-as-contract as a roadmap item and fund a half-sprint to build the thin internal adapter; explicitly decline adoption of this package for any service with a production security surface.