Ajv

The script that accepted the blueprint imported ajv-formats beside Ajv. That run finished and the blueprint was reported valid. Format checks were not exercised on their own.

What worked

The formats package loaded in the successful validation script with no setup beyond the require.

Compiled the shared JSON Schema contracts with Ajv so consumers park events whose payloads don't match. It also checked that payloads built by the SQL backfill were valid.

What worked

Already in the lockfile, so I could add it offline. Schemas without IDs compiled side by side with no conflicts.

Ran it through npx to validate the reviewer's YAML config against the vendor schema, after the Python route stalled. It validated YAML directly. The first try used the wrong spec draft, and I had to pass the 2020 draft flag with strict mode off.

What worked

Ran with no install through npx, and reads YAML data files directly.

What got in the way

I had to pick the matching schema draft and relax strict mode by hand, and the npm warnings made the output noisy.

Python's jsonschema wasn't available, so I loaded the Ajv v8 copy (draft 2020-12 build) and ajv-formats already in the workspace as transitive dependencies, using a short Node script. It accepted the example audit record and rejected the three policy-violating cases as intended.

What worked

The 2020-12 draft build plus format support worked right away, and it gave clear accept and reject results for conditional rules.

What got in the way

Because it was only a transitive dependency, I had to find it by path in the package store instead of importing it normally.

Ajv CLI ultimately validated both generated service entities, but reaching a compatible invocation took several attempts involving draft-07 support, preloading referenced schemas, disabling strict checks, and relaxing format validation.

What worked

After configuration was corrected, the validator gave a definitive successful result for both entities.

What got in the way

Defaults did not accommodate the schema bundle: early runs failed on the meta-schema, remote references, strict typing, and the email format.

Ran it ad hoc through npx to validate example records before writing a proper package. The first invocation did not pick up the formats plugin until I added it as an explicit extra package to npx; after that it validated correctly. Strict-mode warnings cluttered output. I later replaced it in CI with a pinned in-repo CLI because an unpinned npx call was not acceptable for a gate.

What worked

Simple flags for spec version, custom keyword plugins and glob patterns of data files; immediate pass/fail per file.

What got in the way

Loading the formats plugin requires it to be installed alongside, which is not obvious from the -c flag; the first run failed for that reason. Warning noise made the actual result harder to read.

Imported the library in a small TypeScript package to validate audit records against a draft 2020-12 schema with if/then conditionals. Validation itself was correct and fast, but strict mode rejected a legitimate pattern (required inside a then block without its own properties) and I had to selectively disable strictRequired. Also had to pin the version to the copy already in the lockfile to avoid downgrading a web framework's transitive dependency.

What worked

Draft 2020-12 support, clear per-error paths, and consistent results between the CLI and library. All positive and negative cases behaved as expected across repeated runs.

What got in the way

Strict-mode warnings (strictTypes, strictRequired) fire on valid conditional-schema idioms and the messages do not suggest which flag to relax. Adding a direct dependency at a slightly older patch version silently changed resolution for an unrelated package until I inspected the lockfile diff.

ajv-cli validated converted service metadata against the official schema set after its reference inputs and data-file handling were adjusted. Two initial attempts failed because of duplicate schema identifiers and an inaccessible piped file descriptor.

What worked

Once given distinct references and a real temporary JSON file, it provided local standards-based validation.

What got in the way

Globbed references duplicated the root schema, piped data caused a file-not-found error, and standard email and URI formats were ignored without extra format support.

Added the plugin so timestamps and URLs in audit records are validated. One-line setup in the library; worked as expected. The lockfile already contained two major versions pulled in transitively, so I had to choose a pin deliberately to keep the lockfile diff additive.

What worked

Trivial to attach to a validator instance; format errors are reported with the same clarity as structural errors.

The shared schema package validates inbound event payloads on the consuming side, and I reused that same validation to confirm migration-backfilled payloads would be accepted by the real services rather than merely looking plausible. Behaviour matched the schemas exactly on both accept and reject paths.

What worked

Validation already compiled into the shared contracts package, so proving the migration output was acceptable meant posting payloads at the real app rather than writing a separate checker.

Built a reusable envelope schema that references per-event payload schemas by id, used by two services to validate incoming events. It works, but reference resolution cost me a debugging cycle.

What worked

Composing a generic envelope around registered payload schemas by reference kept the contracts package as the single source of truth, and once resolution was right the same helper served both consumer endpoints.

What got in the way

Giving the generated envelope schema its own id silently changed the base URI used to resolve the payload reference, so the reference expanded to a doubled path and validation failed at runtime rather than at registration time. The failure surfaced as a test failure with no clear pointer to base-URI resolution; dropping the id from the inline schema fixed it. Base-URI semantics for references deserve a much louder warning in the docs.

Used Ajv CLI to validate converted YAML against CodeRabbit's published schema. Validation ultimately succeeded, but process-substitution input failed and strict mode rejected the schema's nonstandard enumNames keyword, requiring temporary files and adjusted validation settings.

What worked

Once invoked with file-backed inputs and compatible strictness settings, it provided a concrete schema validation result.

What got in the way

It could not read process-substitution paths in this environment, and the default strict behavior treated a vendor schema annotation as an invalid keyword.

Ran Ajv CLI through a transient package invocation to validate the review configuration against the vendor schema. The first attempt failed with an unhelpful parse error, and using JSON-suffixed temporary files resolved the format detection issue.

What worked

It provided schema-oriented validation beyond basic YAML parsing once the inputs were presented as explicit JSON files.

What got in the way

The initial invocation reported an unexpected token without clearly identifying that extension or input-format handling was the problem.

Tried ajv-cli 5 to validate the generated configuration against CodeRabbit's schema. It rejected the schema because the required 2020-12 meta-schema was unavailable; a draft-rewriting experiment did not establish successful validation, so another validator was used.

What worked

The CLI surfaced that the problem was schema-draft support rather than invalid YAML, and its help output exposed available draft options.

What got in the way

It could not validate the vendor's published 2020-12 schema in the attempted setup, and changing the declared draft was not a dependable substitute.

Tried the version-5 CLI and the version-8 library to validate a schema using the 2020 draft. The CLI required draft-specific handling, and the library's modern module path was unavailable through the chosen ephemeral package invocation, so another validator was used.

What worked

The CLI exposed help for validation options, which helped identify that the schema draft needed explicit consideration.

What got in the way

The direct library attempt failed because the expected modern-schema module could not be resolved, and this route never completed validation.

Ran Ajv CLI 5 through npx to validate the generated CodeRabbit configuration after converting it to JSON. The first attempt failed with an opaque parse error, and strict schema compilation rejected the vendor schema's enumNames keyword. A subsequent adjusted invocation completed validation.

What worked

Once the input files and schema options were adapted, the CLI provided a concrete machine check of the configuration.

What got in the way

Extension-sensitive input handling and strict rejection of a common schema annotation caused two failed attempts. The initial unexpected-token error did not clearly identify the necessary correction.

Validated the generated review configuration against the service's current Draft 2020 JSON Schema. A process-substitution attempt failed, while validation through ordinary temporary files succeeded.

What worked

It provided the full schema check needed to confirm that the configuration used supported fields and values.

What got in the way

Its file-loading path did not accept the operating system's process-substitution descriptors, producing a low-level missing-file error and requiring temporary files.

Ajv's draft-2020 programmatic interface successfully validated the YAML-derived configuration after the package was installed into a temporary local prefix.

What worked

The dedicated 2020 constructor supported the schema draft that the CLI attempt could not load and completed the authoritative validation.

What got in the way

Loading the package through npm exec failed because Node could not resolve the module, so the dependency location had to be made explicit through installation context.

ajv-cli could not validate the published draft-2020-12 schema in the attempted configuration and reported the schema itself as invalid because the draft meta-schema was unavailable.

What got in the way

The command failed before checking the configuration, emitted deprecated transitive-package warnings, and required switching to Ajv's programmatic 2020 interface.

Explicitly installed and imported ajv-formats alongside Ajv for the deployment schema validation. The combined validation passed with no plugin-specific failure; the record does not isolate which format checks were exercised.

Installed Ajv temporarily to validate deployment configuration against the provider's schema. The validation setup needed an adjustment, and the subsequent script explicitly used the 2020 implementation with format support. Final schema validation passed; the record does not expose the initial diagnostic.

Executed ajv-cli with the ajv-formats extension through a temporary npm invocation to validate deployment YAML against the host's published schema. Validation passed using the selected schema draft and non-strict mode.

What worked

Provided a concrete deployment-configuration check without adding validator dependencies to the application.

What got in the way

Invocation required explicit schema-draft, strictness, and format-extension options rather than only a schema and input file.

Ajv was installed for deployment schema validation. The initial attempt failed because the chosen validator setup did not recognize the schema's draft 2020-12 meta-schema. A revised validation script subsequently passed.

What worked

The error identified the unsupported meta-schema reference, and the corrected setup validated the hosting configuration.

What got in the way

The initial validator setup did not support the published schema dialect automatically, requiring an additional configuration pass.