- Can I use mrsuh/json-validation-bundle in a Laravel application?
- Not directly. The package is a Symfony bundle: its entry point, DI extension, configuration tree, and request/response subscribers are bound to the Symfony kernel lifecycle, and Laravel does not autoload bundles or read services.yaml. The reusable asset is the JSON Schema validation core behind the annotation, not the integration layer. In Laravel you would either extract that engine into a middleware or custom Rule, or depend on the underlying schema validator library directly.
- How do I install mrsuh/json-validation-bundle?
- Composer require mrsuh/json-validation-bundle, then register the bundle in config/bundles.php in a Symfony app. In Laravel the equivalent step does not exist, so the service provider auto-discovery mechanism will not wire the validator for you. If you install it in Laravel without registering the bundle, you must instantiate the validator service manually, which pulls in symfony/http-kernel, config, and dependency-injection as transitive dependencies.
- Which JSON Schema draft does this bundle support?
- The overview does not state the supported draft, so treat this as an open question and confirm it before committing. Draft support (04, 06, 07, 2019-09, or 2020-12) determines whether you can reuse OpenAPI component schemas verbatim. If you need 2019-09 or 2020-12 features like unevaluatedProperties, verify against the actual code rather than the README.
- What are the Symfony and Laravel version constraints?
- This matters more than usual because Laravel 10, 11, and 12 pin Symfony components at ^6 or ^7. If the bundle requires symfony/http-kernel ^4 or ^5, Composer will either fail to resolve or force a downgrade of core Laravel dependencies, which is not acceptable. Run a resolution check on a scratch branch before any design work; a failure there ends the evaluation quickly. The last release was in March 2023, so Symfony 7 and PHP 8.4 support are unlikely to be tested.
- How do I validate request JSON against a schema in Laravel without the Symfony bundle?
- Write a small middleware that decodes the request body and passes it to a JSON Schema validator, then maps failures into Laravel's 422 validation response. Alternatively wrap the same call in a custom Rule object and use it inside a FormRequest. Either approach is roughly a hundred lines of glue and avoids dragging in a parallel HTTP kernel stack. The important step is to identify which schema validator the bundle wraps and depend on that library directly.
- Is mrsuh/json-validation-bundle actively maintained?
- The assessment is adverse: around 17 stars, zero dependents, and a release cadence that stopped in March 2023. There is no evidence of testing against PHP 8.3 or 8.4, no security response process, and no downstream population to surface regressions. MIT licensing removes legal friction but not maintenance obligation, so the realistic risk is abandonment rather than malice. The codebase is small enough to audit in an afternoon, which lowers supply-chain exposure considerably.
- Does it support $ref resolution across files and URLs?
- The context does not confirm this, so check the source before relying on it. If you reuse OpenAPI component schemas, cross-file $ref resolution is essential, and remote $ref fetching should be disabled by default to avoid outbound HTTP calls at request time. Treat any default-on remote fetching as a production concern and turn it off explicitly.
- How do I map schema validation errors into Laravel's 422 response?
- The bundle surfaces constraint-based error messages through Symfony's validator component, so the error shape will be a ConstraintViolationList rather than Laravel's message bag. You will need a mapping layer that converts each violation into a field-keyed message compatible with Laravel's validation exception contract. Capture the actual error output from three representative payloads during a short spike so the mapping is based on real data, not assumptions.
- What are the alternatives for JSON Schema validation in Laravel?
- Depend directly on a maintained JSON Schema validator package and write your own middleware or Rule; that is the highest-leverage, lowest-risk path. If the bundle turns out to wrap a bespoke validator rather than a known OSS library, fork the repository into your own namespace and own it instead of depending on an unmaintained upstream transitively. Either way, keep the schema authoring as the source of truth and add CI contract tests around it.
- Should response validation run in production or only in tests?
- Confine response validation to the test suite. Running it on every production response is a latency tax with little runtime value, since a mismatch tells you about your own code rather than about the caller. Request validation is the opposite: run it in production, ideally starting in log-only shadow mode on existing endpoints before enforcing it on new ones. Pin any forked package to an exact version and avoid floating constraints on a package with no recent releases.