Bundling JSON Schema itself

[emetsger]

👋 Hello, I'm a Go/Java user and so typescript is foreign territory for me.

I'm using a Go library to validate a schema which uses regexes. The Go library claims my pattern is not a supported regex per JSON Schema:

compilation failed: '/properties/name/pattern' does not validate with https://json-schema.org/draft/2020-12/schema#/allOf/1/$ref/properties/properties/additionalProperties/$dynamicRef/allOf/3/$ref/properties/pattern/format

So my next step is to look at the meta schema for JSON Schema to actually see what is a valid/supported regex, and I can't for the life of me resolve the json path on the web: /allOf/1/$ref/properties/properties/additionalProperties/$dynamicRef/allOf/3/$ref/properties/pattern/format

• Navigating to https://json-schema.org/draft/2020-12/schema#/allOf/1/$ref/properties/properties/additionalProperties/$dynamicRef/allOf/3/$ref/properties/pattern/format in a browser doesn't give me what I want.
• I can traverse https://json-schema.org/draft/2020-12/schema --> https://json-schema.org/draft/2020-12/meta/applicator, but I'm unable to go any further because I can't divine the uris produced by dynamicRef.

So, what I wanted to do next was to bundle the JSON API draft 2020-12 schema (i.e., resolve all the $refs and pull everything into a single document), then locate the relevant portion of the schema.

Would you be able to help out a Gopher with this particular use case? What would be an example ts script that would bundle the JSON Schema itself?

EDIT: I'm just looking for a bundled version of the 2020-12 draft schema, so if there is a copy of it somewhere on the web, I can just grab it. But my googling and reading of the spec documents didn't provide an answer (or I've missed something obvious), so that's why I've opened this thread.

Many thanks!

[jdesrosiers]

I happen to have a gist of the bundled 2020-12 meta-schema you can look at, but it's not going to help you. The URI in that error message is invalid. The correct URI should be, https://json-schema.org/draft/2020-12/meta/validation#/properties/pattern/format. The constraint that's failing is "format": "regex". The "regex" format is defined as follows.

A regular expression, which SHOULD be valid according to the ECMA-262 regular expression dialect.

Implementations that validate formats MUST accept at least the subset of ECMA-262 defined in the Regular Expressions Section 4.3 section of this specification, and SHOULD accept all valid ECMA-262 expressions.

• https://json-schema.org/draft/2020-12/json-schema-validation#section-7.3.8

In practice, implementations will use whatever regex implementation is available to them. You'll have to consult the specific implementation you're using to know why you're regex is getting rejected.

About that bogus URI, the path represented there is the evaluation path. It's not a location, it's a list of all the keywords that were encountered while evaluating the schema. A lot of implementations use the evaluation path to communicate errors. I find it to be somewhere between useless and harmful. In any case, it's absolutely incorrect to use an evaluation path as a JSON Pointer in a URI the way you see in the error message.

[GabenGar]

How do you bundle a metaschema with this package? The one in the gist is deprecated.
While using this code, which I assume the "modern way":

import { bundle } from "@hyperjump/json-schema/bundle";
import { exit } from "process";

await bundleMetaSchema().catch((error) => {
  console.error(error);
  exit(1);
});

async function bundleMetaSchema() {
  const metaSchema = await bundle("https://json-schema.org/draft/2020-12/schema");

  console.log(JSON.stringify(metaSchema, null, "  "));
}

I get this error:

RetrievalError: Unable to load resource 'https://json-schema.org/draft/2020-12/schema'.
    at get ({project}/node_modules/@hyperjump/browser/lib/browser/browser.js:29:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    ... 3 lines matching cause stack trace ...
    at async {project}/packages/json-schema-to-typescript/dist/scripts/bundle.js:3:1 {
  [cause]: UnsupportedMediaTypeError: 'application/schema+json' is not supported. Use the 'addMediaTypePlugin' function to add support for this media type.
      at parseResponse ({project}/node_modules/@hyperjump/browser/lib/media-types/media-types.js:26:11)
      at get ({project}/node_modules/@hyperjump/browser/lib/browser/browser.js:24:32)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async getSchema ({project}/node_modules/@hyperjump/json-schema/lib/schema.js:31:18)
      at async bundle ({project}/node_modules/@hyperjump/json-schema/bundle/index.js:26:22)
      at async bundleMetaSchema ({project}/packages/json-schema-to-typescript/dist/scripts/bundle.js:8:24)
      at async {project}/packages/json-schema-to-typescript/dist/scripts/bundle.js:3:1 {
    mediaType: 'application/schema+json'
  }
}

[jdesrosiers]

In v1 you need to import support for each dialect you want support for. Since you didn't import any, no dialects are supported including 2020-12. Add import "@hyperjump/json-schema/draft-2020-12" to your script and it should work.

(I realize this new approach is less user friendly and it's easy to miss this detail in the README. I made this choice because it allows for smaller bundle sizes in environments where that's important.)

[GabenGar]

But why does it have to rely on a side effect import in the first place? This kind of syntax is only used as a duct tape for ancient modules or meme modules like .css in bundlers.
From the readme I assumed I don't need to import registerSchema(), because this package should be aware of draft-2020-12 and most likely store it somewhere in the source code in the first place. But apparently import { registerSchema } from "@hyperjump/json-schema/draft-2020-12" also does some metaschema activation magic in the background?

[jdesrosiers]

Yes, loading the dialect is implicit in the API import. I decided it wasn't user friendly to make users take extra steps to load a dialect and wanted to make it as easy as possible to use in the most common case. So, I decided on the draft-specific imports that provide the API and load the dialect automatically. Obviously it's not a perfect solution and can get confusing when you start needing more than one dialect or are doing something a little less common like in this situation. I'm not entirely happy with the choice and will probably try something different in v2 whenever that might happen, but that was my thought process at the time.