Json Schema Test Suite Laravel Package

Product Decisions This Supports

• Build vs. buy on schema validation. The suite is the closest thing to an objective scorecard for PHP validators (opis/json-schema, justinrainbow/json-schema, swaggest/php-json-schema, netresearch/json-schema). Run each candidate against the drafts you care about and you get a pass-rate matrix instead of marketing claims. That single artifact usually settles the "should we write our own validator?" debate — and the answer is almost always no.
• Draft-support roadmap. Decide whether to commit to draft 2020-12 (or 2019-09) versus staying on draft-07 for another year. The suite's per-draft directories make the gap visible and quantified, which is what you need to price the migration.
• API contract standardization. If you're considering JSON Schema as the contract language for a Laravel API — request validation middleware, webhook ingestion, config-schema validation for published packages — conformance data tells you whether standardizing is safe or whether you must document a supported dialect subset.
• Vendor and customer compatibility commitments. Security questionnaires and enterprise RFPs ask "which JSON Schema draft do you support?" A suite-backed pass rate turns a guess into a defensible answer, and it caps the blast radius of a "we support 2020-12" claim.
• Structured-output / LLM tooling. JSON Schema is the schema language for function calling and structured generation. If that's on the roadmap, validator conformance is a leading indicator of how much edge-case handling you'll inherit.
• Publish-vs-consume for internal packages. Teams shipping Laravel packages that accept schemas (form builders, config validators, rule engines) can cite conformance as a quality bar — or discover they're the ones who need to fix it.
• Incident and escape-hatch planning. Knowing which $ref/unevaluatedProperties/dependentSchemas corners your validator fails tells you which customer payloads will break before they do.

When to Consider This Package

Adopt it when:

• You own or fork a PHP validator, or you're maintaining a validation layer in-house and need a regression corpus that isn't your own test cases.
• You're selecting a validator and the difference between candidates matters commercially — multi-draft support, $ref resolution, annotation collection for error messages.
• You must support multiple drafts concurrently because legacy clients send draft-07 while new work targets 2020-12.
• Schema validation is a product surface, not an implementation detail: API gateways, webhook fan-in, low-code form engines, contract testing in CI.
• You're prepared to treat it as a vendored fixture corpus with a CI harness you write — there is no first-class Composer package, no PHP runner, and no support contract.

Look elsewhere when:

• You only need to validate a few request payloads in a Laravel app. Use a validator behind a FormRequest; you don't need the suite. This is the common case and it's worth saying out loud.
• You want PHPUnit-native ergonomics out of the box. You'll be writing a data-provider generator that maps the suite's JSON files and $comment/optional/format annotations into test cases — budget one to two engineering weeks, not an afternoon.
• You need vendor support, SLAs, or a release cadence you can plan against. Last release is May 2023; it's a spec-tracking artifact, and it will not fix your bugs.
• Your usage is OpenAPI-shaped only. A targeted subset harness will be more actionable than the full spec surface.
• Nobody owns validator internals. The suite produces data, not a verdict. Without an owner who can act on failures, it becomes a red CI job people mute.

How to Pitch It (Stakeholders)

One line: A free, MIT-licensed, official conformance test corpus that turns "does our JSON Schema support actually work?" from an opinion into a number.

For executives: Adopting it costs a vendored directory and a CI job, and it de-risks two things we're already paying for — validator selection and interoperability claims in security reviews. It's a benchmark, not a dependency: no runtime footprint, no license cost, no lock-in. The honest caveats are that it has no support contract and no releases since 2023, so it enters our stack as test data with an owner, not as a supported library.

For engineering: This is the official suite the PHP validator ecosystem already tests against, so aligning with it means our failures are real spec failures, not our own invented edge cases. Expect it to find genuine bugs on day one — particularly around $ref sibling keywords, unevaluatedProperties, and format assertion semantics. We write the runner; the suite supplies the truth. Treat draft coverage as a matrix, gate CI on the drafts we publicly support, and let the optional/format cases run informationally.

What it is not: not a Laravel or PHP package, not a runtime validator, not a substitute for the library you'll actually ship. It's the ruler, not the thing being measured — and the decision it enables is which ruler we hand to customers.