Json Validation Bundle Laravel Package

Technical Evaluation

Architecture fit

• Despite the brief's framing, this is not a Laravel package — it is a Symfony bundle (HeroJsonValidationBundle), registered via AppKernel/bundles.php and configured through a DependencyInjection extension. In a Laravel codebase there is no bundle kernel to register it with, so the integration surface simply does not exist. Adoption in Laravel would mean bypassing the bundle wrapper entirely and pulling the underlying library.
• The bundle is a thin container-wiring layer over justinrainbow/json-schema. It contributes no validation logic of its own; its only value is DI registration and possibly a config-driven schema path. Any architectural benefit is therefore bounded by the underlying library, which is independently installable.
• Key architectural question: if the wrapper adds ~1 service definition over a library we can composer require directly, does the bundle justify a dependency at all?

Integration feasibility

• Practically unfeasible as a bundle: 0 stars, 0 dependents, no ecosystem signal, and the repo naming/era suggests Symfony 2.x. That implies PHP 5.x-era constraints in composer.json (symfony/symfony: ~2.x, justinrainbow/json-schema: ~1.x), which conflict with Symfony 6/7 (symfony/framework-bundle ^6|^7) and PHP 8.1+.
• Even if the constraints were loosened, Symfony's container changed materially (autowiring defaults, AbstractBundle, attribute-based config, removal of getRootNode conventions). A 2013-era extension will likely fail to compile on modern kernels.
• For Laravel specifically: no service provider, no facade, no config publishing, no queue/validation rule integration. Wiring would be a hand-written provider around the raw library — at which point the package contributes nothing.

Technical risk

• Abandonment risk: high. Zero stars/dependents plus an unpinned maintenance posture means no security patching path. Composer audit surfaces would be blind to it.
• Supply-chain risk: low-moderate. MIT licensed, small surface, but an unmaintained transitive dep on an old justinrainbow/json-schema major is a real vulnerability-adjacent concern (that library had CVEs in older lines around $ref resolution / remote schema fetching).
• Behavioral risk: draft-04 only semantics via justinrainbow; no JSON Schema 2019-09/2020-12 support. If product requirements include modern schema features (unevaluatedProperties, $dynamicRef), this is a dead end.
• Key questions: What JSON Schema draft do our payloads target? Do we need $ref resolution against remote or local registries? Is schema validation on the request path (latency-sensitive) or in async consumers?

Verdict on the wrapper Do not adopt the bundle. If JSON Schema validation is required, evaluate opis/json-schema (modern drafts, actively maintained, framework-agnostic) or justinrainbow/json-schema directly at a current major. In Laravel, wrap whichever library we choose in a first-party service provider — roughly the same effort as retrofitting this bundle, with a maintainable upgrade path.

Integration Approach

Stack fit

• Laravel: no fit as a bundle. The only viable path is composer require justinrainbow/json-schema (or opis/json-schema) directly and binding a validator service in a first-party provider. Recommended pattern: a JsonSchemaValidator contract in app/Support (or a small internal package), resolved via the container, injected into FormRequests, jobs, and webhook handlers.
• Symfony (if that is actually the target): prefer direct library use plus a small compiler-pass-free service definition over an unmaintained bundle.

Migration path

1. Inventory existing JSON Schema artifacts (files, $ids, drafts, $ref graph).
2. Pick the validation engine based on draft support, not on this wrapper.
3. Implement a thin adapter interface (validate(array $payload, string $schemaRef): ValidationResult) so the engine is swappable.
4. Wire the adapter into Laravel's container; expose it as a custom validation rule (JsonSchema) for request-level use and as a job middleware for consumer-side use.
5. Only if the team still wants the bundle: fork it, bump constraints, and treat it as internal — but the fork cost exceeds the adapter cost.

Compatibility

• Assume incompatible with PHP 8.1+ and Symfony 6/7 without a fork. Laravel 10/11 support is non-existent by construction.
• justinrainbow/json-schema itself is usable on modern PHP, but check the pinned major for PHP 8.2/8.3 deprecations and $ref remote-fetch behavior (disable remote resolution explicitly in config to avoid SSRF in webhook paths).

Sequencing

• Phase 1 (1 sprint): evaluate opis/json-schema vs justinrainbow against our actual schema corpus; produce a compatibility matrix on draft support and $ref handling.
• Phase 2: build the adapter + Laravel provider; land a single high-value validation site (e.g., inbound webhook) behind a feature flag.
• Phase 3: backfill other call sites; add contract tests against a frozen schema fixture set.
• Phase 4: retire any legacy ad-hoc validation. Explicitly do not schedule bundle adoption.

Operational Impact

Maintenance

• Bundle: unmaintainable in practice — no upstream, no issue triage, no release cadence. Every framework upgrade becomes a fork-and-patch exercise. Owning a fork of a DI wrapper around a library is pure overhead with no product value.
• Adapter approach: maintenance burden is the underlying engine's release cadence. opis/json-schema is actively maintained; justinrainbow is stable but slower-moving. Either is a defined, tractable dependency.

Support

• No vendor, no community. Escalation path is "read the source." Not acceptable for a validation layer that gates data integrity on the request path.
• Internal support model: the adapter interface is the contract; on-call runbooks reference engine docs, not this repo.

Scaling

• JSON Schema validation is CPU-bound and dominated by schema compilation, not payload size. Compile/cache schemas once (per-process or in a cache store keyed by schema hash) and reuse; do not re-parse per request.
• Watch $ref resolution: remote refs introduce network I/O and latency variance. Resolve locally or pre-bundle schemas at build time.
• For high-throughput consumers (queue workers, webhooks), benchmark against our largest realistic payloads before committing; validation can be a meaningful fraction of per-message cost.

Failure modes

• Schema drift: schema and producer diverge silently; validation passes but downstream logic breaks. Mitigate with schema versioning and contract tests in CI.
• Remote $ref failure/SSRF: a validator that fetches refs becomes an outbound-request vector. Disable remote resolution and pin a local loader.
• Engine upgrade breakage: draft semantics differ subtly (e.g., format as assertion vs annotation). Pin majors and cover with fixture-based regression tests.
• Silent misconfiguration: a bundle-provided default schema path that doesn't resolve can fail open. Ensure validation errors fail closed and are surfaced, not swallowed.
• Container compile failure (bundle path only): a hard boot failure — total outage on deploy, not a degraded mode.

Ramp-up

• Low for the adapter approach: one engineer, under a week, given a defined schema corpus and a single integration point.
• High for the bundle: retrofitting Symfony 2-era DI conventions to a modern framework is unfamiliar work with no reference implementations and no community to consult. Estimated effort exceeds building the adapter from scratch, with a worse end state.
• Recommendation to stakeholders: do not adopt. Redirect the evaluation budget to engine selection (opis/json-schema first) and a first-party Laravel adapter.