diff --git a/.eslintrc.json b/.eslintrc.json new file mode 100644 index 00000000..585b9d92 --- /dev/null +++ b/.eslintrc.json @@ -0,0 +1,35 @@ +{ + "root": true, + "env": { + "es6": true, + "node": true + }, + "parserOptions": { + "ecmaVersion": 2020, + "sourceType": "module" + }, + "extends": [ + "eslint:recommended", + "plugin:import/recommended" + ], + "plugins": ["import"], + "rules": { + "array-bracket-spacing": "error", + "arrow-parens": "error", + "comma-dangle": "error", + "dot-location": ["error", "property"], + "eol-last": "error", + "generator-star-spacing": ["error", { "before": false, "after": true }], + "indent": ["error", 2, { "ignoreComments": true, "SwitchCase": 1 }], + "linebreak-style": "error", + "no-console": ["error", { "allow": ["error"] }], + "no-trailing-spaces": "error", + "no-unused-vars": ["error", { "argsIgnorePattern": "_.*" }], + "prefer-const": ["error", { "destructuring": "all" }], + "semi": "error", + "quotes": ["error", "double", { "allowTemplateLiterals": true }] + }, + "settings": { + "import/resolver": "node" + } +} diff --git a/.gitignore b/.gitignore index f375fa6e..47062da0 100644 --- a/.gitignore +++ b/.gitignore @@ -7,3 +7,8 @@ relative-json-pointer.txt # For the Python enviornment .venv + +# For the node-based build tools +node_modules/ + +.env diff --git a/Makefile b/Makefile index a81ca9b4..4ad478e3 100644 --- a/Makefile +++ b/Makefile @@ -2,8 +2,6 @@ XML2RFC ?= xml2rfc VENV ?= .venv OUT = \ - jsonschema-core.html jsonschema-core.txt \ - jsonschema-validation.html jsonschema-validation.txt \ relative-json-pointer.html relative-json-pointer.txt all: $(VENV) $(OUT) diff --git a/README.md b/README.md index 58007547..44e55482 100644 --- a/README.md +++ b/README.md @@ -22,29 +22,91 @@ For the current status of issues and pull requests, please see the following lab Labels are assigned based on [Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). -## Contents - -* Makefile - scripts to build the Internet-Draft txt/html -* _Internet-Draft sources_ - * jsonschema-core.xml - source for JSON Schema's "core" I-D - * jsonschema-validation.xml - source for the validation vocabulary I-D - * relative-json-pointer.xml - source for the Relative JSON Pointer I-D -* _meta-schemas and recommended output formats_ - * schema.json - JSON Schema "core" and Validation meta-schema - -The Makefile will create the necessary Python venv for you as part of the regular make target. - -`make clean` will remove all output including the venv. To clean just the spec output and -keep the venv, use `make spec-clean`. - -If you want to run `xml2rfc` manually after running make for the first time, you will -need to activate the virtual environment: - -```sh -source .venv/bin/activate -``` - -The version of "xml2rfc" that this project uses is updated by modifying `requirements.in` and running `pip-compile requirements.in`. +## Authoring and Building + +### Specification +To build the spec files to HTML from the Markdown sources, run `npm run build`. +You can also build each individually with `npm run build-core` and `npm run +build-validation`. + +The spec is built using [Remark](https://remark.js.org/), a markdown engine with +good support for plugins and lots of existing plugins we can use. + +#### Plugins +The following is a not-necessarily-complete list of configured plugins and the +features they make available to you. + +- [remark-lint](https://github.com/remarkjs/remark-lint) -- Enforce markdown + styles guide. +- [remark-validate-links](https://github.com/remarkjs/remark-validate-links) -- + Check for broken links. +- [remark-gfm](https://github.com/remarkjs/remark-gfm) -- Adds support for + Github Flavored Markdown specific markdown features such as autolink literals, + footnotes, strikethrough, tables, and tasklists. +- [remark-heading-id](https://github.com/imcuttle/remark-heading-id) -- Adds + support for `{#my-anchor}` syntax to add an `id` to an element so it can be + referenced using URI fragment syntax. +- [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark-headings.js) + -- A collection of enhancements for headings. + - Adds hierarchical section numbers to headings. + - Use the `[Appendix]` prefix on headings that should be numbered as an + appendix. + - Adds id anchors to headers that don't have one + - Example: `#section-2-13` + - Example: `#appendix-a` + - Makes the heading a link utilizing its anchor +- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/remark-reference-link.js) + -- Adds new syntax for referencing a section of the spec using the section + number as the link text. + - Example: + ```markdown + ## Foo {#foo} + + ## Bar + This is covered in {{foo}} // --> Renders to "This is covered in [Section 2.3](#foo)" + - Link text will use "Section" or "Appendix" as needed + ``` +- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark-table-of-contents.js) + -- Adds a table of contents in a section with a header called "Table of + Contents". +- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/remark-code-titles.js) + -- Add titles to code blocks + - Example: + ```markdown + \`\`\`jsonschema "My Fun Title" + { "type": "string" } + \`\`\` + ``` + - The languages `jsonschema` and `json` have special styling + - The title will be parsed as a JSON string, but you have to double escape + escaped characters. So, to get `My "quoted" title`, you would need to be + `"My \\\\"quoted\\\\" title"`. +- [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- + Syntax highlighting and more using https://torchlight.dev. Features include + line numbers and line highlighting. +- [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) + -- Add a callout box using the following syntax. Supported container types are + `warning`, `note`, and `experimental`. + + ``` + ::: {type} {title} + {content} + ::: + ``` + +### Internet-Drafts +To build components that are being maintained as IETF Internet-Drafts, run +`make`. The Makefile will create the necessary Python venv for you as part of +the regular make target. + +`make clean` will remove all output including the venv. To clean just the spec +output and keep the venv, use `make spec-clean`. + +If you want to run `xml2rfc` manually after running make for the first time, you +will need to activate the virtual environment: `source .venv/bin/activate`. + +The version of "xml2rfc" that this project uses is updated by modifying +`requirements.in` and running `pip-compile requirements.in`. Descriptions of the xml2rfc, I-D documents, and RFC processes: diff --git a/build/build.js b/build/build.js new file mode 100644 index 00000000..e8b3f0ef --- /dev/null +++ b/build/build.js @@ -0,0 +1,152 @@ +import dotenv from "dotenv"; +import { readFileSync, writeFileSync } from "node:fs"; +import { reporter } from "vfile-reporter"; +import { remark } from "remark"; +import remarkCodeTitles from "./remark-code-titles.js"; +import remarkFlexibleContainers from "remark-flexible-containers"; +import remarkGfm from "remark-gfm"; +import remarkHeadingId from "remark-heading-id"; +import remarkHeadings from "./remark-headings.js"; +import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; +import remarkRehype from "remark-rehype"; +import remarkReferenceLinks from "./remark-reference-links.js"; +import remarkTableOfContents from "./remark-table-of-contents.js"; +import remarkTorchLight from "remark-torchlight"; +import remarkValidateLinks from "remark-validate-links"; +import rehypeStringify from "rehype-stringify"; + + +dotenv.config(); + +(async function () { + const md = readFileSync(0, "utf-8"); + const html = await remark() + .use(remarkPresetLintMarkdownStyleGuide) + .use(remarkGfm) + .use(remarkHeadingId) + .use(remarkHeadings, { + startDepth: 2, + skip: ["Abstract", "Note to Readers", "Table of Contents", "Authors' Addresses", "\\[.*\\]", "draft-.*"] + }) + .use(remarkReferenceLinks) + .use(remarkFlexibleContainers) + .use(remarkCodeTitles) + .use(remarkTorchLight) + .use(remarkTableOfContents, { + startDepth: 2, + skip: ["Abstract", "Note to Readers", "\\[.*\\]", "Authors' Addresses", "draft-.*"] + }) + .use(remarkValidateLinks) + .use(remarkRehype) + .use(rehypeStringify) + .process(md); + + writeFileSync(1, ` + + + + + + + + ${html.toString()} + +`); + + console.error(reporter(html)); +}()); diff --git a/build/remark-code-titles.js b/build/remark-code-titles.js new file mode 100644 index 00000000..12986a51 --- /dev/null +++ b/build/remark-code-titles.js @@ -0,0 +1,65 @@ +import { visit } from "unist-util-visit"; +import { text } from "mdast-builder"; + + +const hexdig = `[0-9a-fA-F]`; +const char = `(?:\\\\["\\/\\\\brfnt]|\\\\u${hexdig}{4}|[^"\\\\])`; +const jsonStringPattern = new RegExp(`^"${char}*"`); + +const remarkNumberHeadings = () => (tree) => { + visit(tree, "code", (codeNode, index, parent) => { + // Support title without a language + if (codeNode.lang && codeNode.lang[0] === "\"") { + codeNode.meta = `${codeNode.lang} ${codeNode.meta}`; + codeNode.lang = null; + } + + let title = ""; + const titleClasses = ["remark-code-title"]; + + const language = codeNode.lang ?? ""; + if (language.toLowerCase() === "jsonschema") { + codeNode.lang = "json"; + title = "JSON Schema"; + titleClasses.push("code-title-jsonschema"); + } else if (language.toLowerCase() === "json") { + title = "JSON"; + titleClasses.push("code-title-json"); + } else { + titleClasses.push("code-title-unknown"); + } + + if ("meta" in codeNode) { + const match = jsonStringPattern.exec(codeNode.meta); + if (match) { + const customTitle = JSON.parse(match[0]); + title = title ? `${title} - ${customTitle}` : customTitle; + codeNode.meta = codeNode.meta.slice(match[0].length).trim(); + } + } + + const containerChildren = []; + if (title) { + const titleNode = div([text(title)], { className: titleClasses }); + containerChildren.push(titleNode); + } + containerChildren.push(codeNode); + + const wrappedCodeNode = div(containerChildren, { className: ["remark-code-container"] }); + + parent.children.splice(index, 1, wrappedCodeNode); + }); +}; + +const div = (children, properties) => { + return { + type: "container", + children, + data: { + hName: "div", + hProperties: properties + } + }; +}; + +export default remarkNumberHeadings; diff --git a/build/remark-headings.js b/build/remark-headings.js new file mode 100644 index 00000000..6cecefcd --- /dev/null +++ b/build/remark-headings.js @@ -0,0 +1,97 @@ +import { visit } from "unist-util-visit"; +import { link, text } from "mdast-builder"; +import { findAndReplace } from "mdast-util-find-and-replace"; +import { toString as nodeToString } from "mdast-util-to-string"; + + +const defaultOptions = { + startDepth: 1, + skip: [], + appendixToken: "[Appendix]", + appendixPrefix: "Appendix" +}; + +const remarkNumberHeadings = (options) => (tree, file) => { + options = { ...defaultOptions, ...options }; + options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); + + // Auto-number headings + let sectionNumbers = []; + + visit(tree, "heading", (headingNode) => { + if (headingNode.depth < options.startDepth) { + return; + } + + const headingText = nodeToString(headingNode); + if (options.skip.test(headingText)) { + return; + } + + if (!("data" in headingNode)) { + headingNode.data = {}; + } + + if (!("hProperties" in headingNode.data)) { + headingNode.data.hProperties = {}; + } + + if (headingText.startsWith(options.appendixToken)) { + findAndReplace(headingNode, [options.appendixToken]); + + const currentIndex = typeof sectionNumbers[headingNode.depth] === "string" + ? sectionNumbers[headingNode.depth] + : "@"; + sectionNumbers[headingNode.depth] = String.fromCharCode(currentIndex.charCodeAt(0) + 1); + sectionNumbers = sectionNumbers.slice(0, headingNode.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, headingNode.depth + 1).join("."); + headingNode.data.section = `${options.appendixPrefix} ${sectionNumber}`; + + headingNode.children.splice(0, 0, text(`${headingNode.data.section}. `)); + } else { + sectionNumbers[headingNode.depth] = (sectionNumbers[headingNode.depth] ?? 0) + 1; + sectionNumbers = sectionNumbers.slice(0, headingNode.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, headingNode.depth + 1).join("."); + const prefix = typeof sectionNumbers[options.startDepth] === "string" + ? options.appendixPrefix + : "Section"; + headingNode.data.section = `${prefix} ${sectionNumber}`; + + headingNode.children.splice(0, 0, text(`${sectionNumber}. `)); + } + + if (!("id" in headingNode.data)) { + const sectionSlug = headingNode.data?.id + ?? headingNode.data.section.replaceAll(/[ .]/g, "-").toLowerCase(); + headingNode.data.hProperties.id = sectionSlug; + headingNode.data.id = sectionSlug; + } + }); + + // Build headings data used by ./remark-reference-links.js + if (!("data" in file)) { + file.data = {}; + } + + file.data.headings = {}; + + visit(tree, "heading", (headingNode) => { + if (headingNode.data?.id) { + if (headingNode.data.id in file.data.headings) { + file.message(`Found duplicate heading id "${headingNode.data.id}"`); + } + file.data.headings[headingNode.data.id] = headingNode; + } + }); + + // Make heading a link + visit(tree, "heading", (headingNode) => { + if (headingNode.data?.id) { + headingNode.children = [link(`#${headingNode.data.id}`, "", headingNode.children)]; + } + }); +}; + +export default remarkNumberHeadings; diff --git a/build/remark-reference-links.js b/build/remark-reference-links.js new file mode 100644 index 00000000..16af2928 --- /dev/null +++ b/build/remark-reference-links.js @@ -0,0 +1,21 @@ +import { text, link } from "mdast-builder"; +import { toString as nodeToString } from "mdast-util-to-string"; +import { findAndReplace } from "mdast-util-find-and-replace"; + + +const referenceLink = /\{\{(?.*?)\}\}/ug; + +const remarkReferenceLinks = () => (tree, file) => { + findAndReplace(tree, [referenceLink, (value, id) => { + // file.data.headings comes from ./remark-headings.js + if (!(id in file.data.headings)) { + throw Error(`ReferenceLinkError: No header found with id "${id}"`); + } + + const headerText = nodeToString(file.data.headings[id]); + const linkText = text(file.data.headings[id].data.section); + return link(`#${id}`, headerText, [linkText]); + }]); +}; + +export default remarkReferenceLinks; diff --git a/build/remark-table-of-contents.js b/build/remark-table-of-contents.js new file mode 100644 index 00000000..3fbb3bde --- /dev/null +++ b/build/remark-table-of-contents.js @@ -0,0 +1,65 @@ +import { visit } from "unist-util-visit"; +import { list, listItem } from "mdast-builder"; +import { toString as nodeToString } from "mdast-util-to-string"; + + +const defaultOptions = { + heading: "Table of Contents", + startDepth: 1, + skip: [] +}; + +const remarkTableOfContents = (options) => (tree, file) => { + options = { ...defaultOptions, ...options }; + options.skip.push(options.heading); + options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); + + let insertTableOfContents; + + const tableOfContents = list("unordered"); + let currentList = tableOfContents; + const listStack = [currentList]; + let currentDepth = options.startDepth; + + visit(tree, "heading", (headingNode, index, parent) => { + const headingText = nodeToString(headingNode); + + if (headingText === options.heading) { + insertTableOfContents = () => { + parent.children.splice(index + 1, 0, tableOfContents); + }; + } + + if (headingNode.depth < options.startDepth) { + return; + } + + while (headingNode.depth > currentDepth) { + const newList = list("unordered"); + listStack.push(newList); + currentList.children.push(newList); + currentList = newList; + currentDepth++; + } + + while (headingNode.depth < currentDepth) { + listStack.pop(); + currentList = listStack[listStack.length - 1]; + currentDepth--; + } + + if (options.skip.test(headingText)) { + return; + } + + currentList.children.push(listItem(headingNode.children)); + }); + + if (insertTableOfContents) { + insertTableOfContents(); + } else { + file.message(`Table of Contents not added. Add a heading with the text "${options.heading}" or set the 'heading' option to use a different heading.`); + } +}; + +export default remarkTableOfContents; diff --git a/jsonschema-core.md b/jsonschema-core.md new file mode 100644 index 00000000..607e35fc --- /dev/null +++ b/jsonschema-core.md @@ -0,0 +1,3413 @@ +# JSON Schema: A Media Type for Describing JSON Documents + +## Abstract + +JSON Schema defines the media type `application/schema+json`, a JSON-based +format for describing the structure of JSON data. JSON Schema asserts what a +JSON document must look like, ways to extract information from it, and how to +interact with it. The `application/schema-instance+json` media type provides +additional feature-rich integration with `application/schema+json` beyond what +can be offered for `application/json` documents. + +## Note to Readers + +The issues list for this draft can be found at +. + +For additional information, see . + +To provide feedback, use this issue tracker, the communication methods listed on +the homepage, or email the document editors. + +## Table of Contents + +## Introduction + +JSON Schema is a JSON media type for defining the structure of JSON data. JSON +Schema is intended to define validation, documentation, hyperlink navigation, +and interaction control of JSON data. + +This specification defines JSON Schema core terminology and mechanisms, +including pointing to another JSON Schema by reference, dereferencing a JSON +Schema reference, specifying the dialect being used, specifying a dialect's +vocabulary requirements, and defining the expected output. + +Other specifications define the vocabularies that perform assertions about +validation, linking, annotation, navigation, and interaction. + +## Conventions and Terminology + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119](#rfc2119). + +The terms "JSON", "JSON text", "JSON value", "member", "element", "object", +"array", "number", "string", "boolean", "true", "false", and "null" in this +document are to be interpreted as defined in [RFC 8259](#rfc8259). + +## Overview + +This document proposes a new media type `application/schema+json` to identify a +JSON Schema for describing JSON data. It also proposes a further optional media +type, `application/schema-instance+json`, to provide additional integration +features. JSON Schemas are themselves JSON documents. This, and related +specifications, define keywords allowing authors to describe JSON data in +several ways. + +JSON Schema uses keywords to assert constraints on JSON instances or annotate +those instances with additional information. Additional keywords are used to +apply assertions and annotations to more complex JSON data structures, or based +on some sort of condition. + +To facilitate re-use, keywords can be organized into vocabularies. A vocabulary +consists of a list of keywords, together with their syntax and semantics. A +dialect is defined as a set of vocabularies and their required support +identified in a meta-schema. + +JSON Schema can be extended either by defining additional vocabularies, or less +formally by defining additional keywords outside of any vocabulary. Unrecognized +individual keywords simply have their values collected as annotations, while the +behavior with respect to an unrecognized vocabulary can be controlled when +declaring which vocabularies are in use. + +This document defines a core vocabulary that MUST be supported by any +implementation, and cannot be disabled. Its keywords are each prefixed with a +"$" character to emphasize their required nature. This vocabulary is essential +to the functioning of the `application/schema+json` media type, and is used to +bootstrap the loading of other vocabularies. + +Additionally, this document defines a RECOMMENDED vocabulary of keywords for +applying subschemas conditionally, and for applying subschemas to the contents +of objects and arrays. Either this vocabulary or one very much like it is +required to write schemas for non-trivial JSON instances, whether those schemas +are intended for assertion validation, annotation, or both. While not part of +the required core vocabulary, for maximum interoperability this additional +vocabulary is included in this document and its use is strongly encouraged. + +Further vocabularies for purposes such as structural validation or hypermedia +annotation are defined in other documents. These other documents each define a +dialect collecting the standard sets of vocabularies needed to write schemas for +that document's purpose. + +## Definitions + +### JSON Document + +A JSON document is an information resource (series of octets) described by the +`application/json` media type. + +In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are +interchangeable because of the data model it defines in {{data-model}}. + +JSON Schema is only defined over JSON documents. However, any document or memory +structure that can be parsed into or processed according to the JSON Schema data +model can be interpreted against a JSON Schema, including media types like +[CBOR](#rfc7049). + +### Instance + +A JSON document to which a schema is applied is known as an "instance". + +JSON Schema is defined over `application/json` or compatible documents, +including media types with the `+json` structured syntax suffix. + +Among these, this specification defines the `application/schema-instance+json` +media type which defines handling for fragments in the IRI. + +#### Instance Data Model {#data-model} + +JSON Schema interprets documents according to a data model. A JSON value +interpreted according to this data model is called an "instance". + +An instance has one of six primitive types, and a range of possible values +depending on the type: + +- *null*: A JSON "null" value +- boolean: A "true" or "false" value, from the JSON "true" or "false" value +- *object*: An unordered set of properties mapping a string to an instance, from + the JSON "object" value +- *array*: An ordered list of instances, from the JSON "array" value +- *number*: An arbitrary-precision, base-10 decimal number value, from the JSON + "number" value +- *string*: A string of Unicode code points, from the JSON "string" value + +Whitespace and formatting concerns, including different lexical representations +of numbers that are equal within the data model, are thus outside the scope of +JSON Schema. JSON Schema [vocabularies](#vocabulary) that wish to work with such +differences in lexical representations SHOULD define keywords to precisely +interpret formatted strings within the data model rather than relying on having +the original JSON representation Unicode characters available. + +Since an object cannot have two properties with the same key, behavior for a +JSON document that tries to define two properties with the same key in a single +object is undefined. + +Note that JSON Schema vocabularies are free to define their own extended type +system. This should not be confused with the core data model types defined here. +As an example, "integer" is a reasonable type for a vocabulary to define as a +value for a keyword, but the data model makes no distinction between integers +and other numbers. + +#### Instance Equality + +Two JSON instances are said to be equal if and only if they are of the same type +and have the same value according to the data model. Specifically, this means: + +- both are null; or +- both are true; or +- both are false; or +- both are strings, and are the same codepoint-for-codepoint; or +- both are numbers, and have the same mathematical value; or +- both are arrays, and have an equal value item-for-item; or +- both are objects, and each property in one has exactly one property with a key + equal to the other's, and that other property has an equal value. + +Implied in this definition is that arrays must be the same length, objects must +have the same number of members, properties in objects are unordered, there is +no way to define multiple properties with the same key, and mere formatting +differences (indentation, placement of commas, trailing zeros) are +insignificant. + +#### Non-JSON Instances + +It is possible to use JSON Schema with a superset of the JSON Schema data model, +where an instance may be outside any of the six JSON data types. + +In this case, annotations still apply; but most validation keywords will not be +useful, as they will always pass or always fail. + +A custom vocabulary may define support for a superset of the core data model. +The schema itself may only be expressible in this superset; for example, to make +use of the `const` keyword. + +### JSON Schema Documents {#schema-document} + +A JSON Schema document, or simply a schema, is a JSON document used to describe +an instance. A schema can itself be interpreted as an instance, but SHOULD +always be given the media type `application/schema+json` rather than +`application/schema-instance+json`. The `application/schema+json` media type is +defined to offer a superset of the fragment identifier syntax and semantics +provided by `application/schema-instance+json`. + +A JSON Schema MUST be an object or a boolean. + +#### JSON Schema Objects and Keywords + +Object properties that are applied to the instance are called keywords, or +schema keywords. Broadly speaking, keywords fall into one of five categories: + +- *identifiers*: control schema identification through setting a IRI for the + schema and/or changing how the base IRI is determined +- *assertions*: produce a boolean result when applied to an instance +- *annotations*: attach information to an instance for application use +- *applicators*: apply one or more subschemas to a particular location in the + instance, and combine or modify their results +- *reserved locations*: do not directly affect results, but reserve a place for + a specific purpose to ensure interoperability + +Keywords may fall into multiple categories, although applicators SHOULD only +produce assertion results based on their subschemas' results. They should not +define additional constraints independent of their subschemas. + +Keywords which are properties within the same schema object are referred to as +adjacent keywords. + +Extension keywords, meaning those defined outside of this document and its +companions, are free to define other behaviors as well. + +A JSON Schema MAY contain properties which are not schema keywords or are not +recognized as schema keywords. The behavior of such keywords is governed by +{{unrecognized}}. + +An empty schema is a JSON Schema with no properties. + +#### Boolean JSON Schemas + +The boolean schema values `true` and `false` are trivial schemas that always +produce themselves as assertion results, regardless of the instance value. They +never produce annotation results. + +These boolean schemas exist to clarify schema author intent and facilitate +schema processing optimizations. They behave identically to the following schema +objects (where `not` is part of the subschema application vocabulary defined in +this document). + +- `true`: Always passes validation, as if the empty schema `{}` +- `false`: Always fails validation, as if the schema `{ "not": {} }` + +While the empty schema object is unambiguous, there are many possible +equivalents to the `false` schema. Using the boolean values ensures that the +intent is clear to both human readers and implementations. + +#### Schema Vocabularies + +A schema vocabulary, or simply a vocabulary, is a set of keywords, their syntax, +and their semantics. A vocabulary is generally organized around a particular +purpose. Different uses of JSON Schema, such as validation, hypermedia, or user +interface generation, will involve different sets of vocabularies. + +Vocabularies are the primary unit of re-use in JSON Schema, as schema authors +can indicate what vocabularies are required or optional in order to process the +schema. Since vocabularies are identified by IRIs in the meta-schema, generic +implementations can load extensions to support previously unknown vocabularies. +While keywords can be supported outside of any vocabulary, there is no analogous +mechanism to indicate individual keyword usage. + +A schema vocabulary can be defined by anything from an informal description to a +standards proposal, depending on the audience and interoperability expectations. +In particular, in order to facilitate vocabulary use within non-public +organizations, a vocabulary specification need not be published outside of its +scope of use. + +#### Meta-Schemas + +A schema that itself describes a schema is called a meta-schema. Meta-schemas +are used to validate JSON Schemas and specify which vocabularies they are using. + +Typically, a meta-schema will specify a set of vocabularies, and validate +schemas that conform to the syntax of those vocabularies. However, meta-schemas +and vocabularies are separate in order to allow meta-schemas to validate schema +conformance more strictly or more loosely than the vocabularies' specifications +call for. Meta-schemas may also describe and validate additional keywords that +are not part of a formal vocabulary. + +#### Root Schema and Subschemas and Resources {#root} + +A JSON Schema resource is a schema which is [canonically](#rfc6596) identified +by an [absolute IRI](#rfc3987). Schema resources MAY also be identified by IRIs, +including IRIs with fragments, if the resulting secondary resource (as defined +by [section 3.5 of RFC 3986](#rfc3986)) is identical to the primary resource. +This can occur with the empty fragment, or when one schema resource is embedded +in another. Any such IRIs with fragments are considered to be non-canonical. + +The root schema is the schema that comprises the entire JSON document in +question. The root schema is always a schema resource, where the IRI is +determined as described in {{initial-base}}.[^1] + +[^1]: Note that documents that embed schemas in another format will not have a +root schema resource in this sense. Exactly how such usages fit with the JSON +Schema document and resource concepts will be clarified in a future draft. + +Some keywords take schemas themselves, allowing JSON Schemas to be nested: + +```jsonschema +{ + "title": "root", + "items": { + "title": "array item" + } +} +``` + +In this example document, the schema titled "array item" is a subschema, and the +schema titled "root" is the root schema. + +As with the root schema, a subschema is either an object or a boolean. + +As discussed in {{id-keyword}}, a JSON Schema document can contain multiple JSON +Schema resources. When used without qualification, the term "root schema" refers +to the document's root schema. In some cases, resource root schemas are +discussed. A resource's root schema is its top-level schema object, which would +also be a document root schema if the resource were to be extracted to a +standalone JSON Schema document. + +Whether multiple schema resources are embedded or linked with a reference, they +are processed in the same way, with the same available behaviors. + +## Fragment Identifiers {#fragments} + +In accordance with section 3.1 of [RFC 6839](#rfc6839), the syntax and semantics +of fragment identifiers specified for any +json media type SHOULD be as +specified for `application/json`. (At publication of this document, there is no +fragment identification syntax defined for `application/json`.) + +Additionally, the `application/schema+json` media type supports two fragment +identifier structures: plain names and JSON Pointers. The +`application/schema-instance+json` media type supports one fragment identifier +structure: JSON Pointers. + +The use of JSON Pointers as IRI fragment identifiers is described in [RFC +6901](#rfc6901). For `application/schema+json`, which supports two fragment +identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, +including the empty string, MUST be interpreted as JSON Pointer fragment +identifiers. + +Per the W3C's [best practices for fragment +identifiers](#w3cwd-fragid-best-practices-20121025), plain name fragment +identifiers in `application/schema+json` are reserved for referencing locally +named schemas. + +Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("\_"), +followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores +("\_"), and periods ("."). This matches the US-ASCII part of XML's [NCName +production](#xml-names), which allows for compatibility with the recommended +plain name [syntax](#w3crec-xptr-framework-20030325) for XML-based media types. + +All fragment identifiers that do not match the JSON Pointer syntax MUST be +interpreted as plain name fragment identifiers. + +Defining and referencing a plain name fragment identifier within an +`application/schema+json` document are specified in the [`$anchor` +keyword](#anchors) section. + +## General Considerations + +### Range of JSON Values + +An instance may be any valid JSON value as defined by [JSON](#rfc8259). JSON +Schema imposes no restrictions on type: JSON Schema can describe any JSON value, +including, for example, null. + +### Programming Language Independence {#language} + +JSON Schema is programming language agnostic, and supports the full range of +values described in the data model. Be aware, however, that some languages and +JSON parsers may not be able to represent in memory the full range of values +describable by JSON. + +### Mathematical Integers {#integers} + +Some programming languages and parsers use different internal representations +for floating point numbers than they do for integers. + +For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional +part. + +### Regular Expressions {#regex} + +Keywords MAY use regular expressions to express constraints, or constrain the +instance value to be a regular expression. These regular expressions SHOULD be +valid according to the regular expression dialect described in [ECMA-262, +section 21.2.1](#ecma262). + +Unless otherwise specified by a keyword, regular expressions MUST NOT be +considered to be implicitly anchored at either end. All regular expression +keywords in this specification and its companion documents are un-anchored. + +Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide +Unicode support, or processed in such a way which provides Unicode support as +defined by ECMA-262. + +Furthermore, given the high disparity in regular expression constructs support, +schema authors SHOULD limit themselves to the following regular expression +tokens: + +- individual Unicode characters, as defined by the [JSON + specification](#rfc8259); +- simple character classes ([abc]), range character classes ([a-z]); +- complemented character classes ([^abc], [^a-z]); +- simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), + and their lazy versions ("+?", "*?", "??"); +- range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most + y, occurrences), {x,} (x occurrences or more), and their lazy versions; +- the beginning-of-input ("^") and end-of-input ("$") anchors; +- simple grouping ("(...)") and alternation ("|"). + +Finally, implementations MUST NOT take regular expressions to be anchored, +neither at the beginning nor at the end. This means, for instance, the pattern +"es" matches "expression". + +### Extending JSON Schema {#extending} + +Additional schema keywords and schema vocabularies MAY be defined by any entity. +Save for explicit agreement, schema authors SHALL NOT expect these additional +keywords and vocabularies to be supported by implementations that do not +explicitly document such support. + +Implementations MAY provide the ability to register or load handlers for +vocabularies that they do not support directly. The exact mechanism for +registering and implementing such handlers is implementation-dependent. + +#### Explicit annotation keywords {#explicit-annotations} + +The values of keywords which begin with "x-" MUST be collected as annotations. + +Keywords which begin with "x-" symbol MUST NOT affect evaluation of a schema in +any way other than annotation collection. + +Consequently, the "x-" prefix is reserved for this purpose, and extension +vocabularies MUST NOT define any keywords which begin with this prefix. + +#### Handling of unrecognized or unsupported keywords {#unrecognized} + +Implementations SHOULD treat keywords they do not recognize, or that they +recognize but do not support, as annotations, where the value of the keyword is +the value of the annotation. Whether an implementation collects these +annotations or not, they MUST otherwise ignore the keywords. + +## Keyword Behaviors + +JSON Schema keywords fall into several general behavior categories. Assertions +validate that an instance satisfies constraints, producing a boolean result. +Annotations attach information that applications may use in any way they see +fit. Applicators apply subschemas to parts of the instance and combine their +results. + +Extension keywords SHOULD stay within these categories, keeping in mind that +annotations in particular are extremely flexible. Complex behavior is usually +better delegated to applications on the basis of annotation data than +implemented directly as schema keywords. However, extension keywords MAY define +other behaviors for specialized purposes. + +Evaluating an instance against a schema involves processing all of the keywords +in the schema against the appropriate locations within the instance. Typically, +applicator keywords are processed until a schema object with no applicators (and +therefore no subschemas) is reached. The appropriate location in the instance is +evaluated against the assertion and annotation keywords in the schema object. +The interactions of those keyword results to produce the schema object results +are governed by {{annot-assert}}, while the relationship of subschema results to +the results of the applicator keyword that applied them is described by +{{applicators}}. + +Evaluation of a parent schema object can complete once all of its subschemas +have been evaluated, although in some circumstances evaluation may be +short-circuited due to assertion results. When annotations are being collected, +some assertion result short-circuiting is not possible due to the need to +examine all subschemas for annotation collection, including those that cannot +further change the assertion result. + +### Lexical Scope and Dynamic Scope {#scopes} + +While most JSON Schema keywords can be evaluated on their own, or at most need +to take into account the values or results of adjacent keywords in the same +schema object, a few have more complex behavior. + +The lexical scope of a keyword is determined by the nested JSON data structure +of objects and arrays. The largest such scope is an entire schema document. The +smallest scope is a single schema object with no subschemas. + +Keywords MAY be defined with a partial value, such as a IRI-reference, which +must be resolved against another value, such as another IRI-reference or a full +IRI, which is found through the lexical structure of the JSON document. The +`$id`, `$ref`, and `$dynamicRef` core keywords, and the "base" JSON Hyper-Schema +keyword, are examples of this sort of behavior. + +Note that some keywords, such as `$schema`, apply to the lexical scope of the +entire schema resource, and therefore MUST only appear in a schema resource's +root schema. + +Other keywords may take into account the dynamic scope that exists during the +evaluation of a schema, typically together with an instance document. The +outermost dynamic scope is the schema object at which processing begins, even if +it is not a schema resource root. The path from this root schema to any +particular keyword (that includes any `$ref` and `$dynamicRef` keywords that may +have been resolved) is considered the keyword's "evaluation path." + +Lexical and dynamic scopes align until a reference keyword is encountered. While +following the reference keyword moves processing from one lexical scope into a +different one, from the perspective of dynamic scope, following a reference is +no different from descending into a subschema present as a value. A keyword on +the far side of that reference that resolves information through the dynamic +scope will consider the originating side of the reference to be their dynamic +parent, rather than examining the local lexically enclosing parent. + +The concept of dynamic scope is primarily used with `$dynamicRef` and +`$dynamicAnchor`, and should be considered an advanced feature and used with +caution when defining additional keywords. It also appears when reporting errors +and collected annotations, as it may be possible to revisit the same lexical +scope repeatedly with different dynamic scopes. In such cases, it is important +to inform the user of the evaluation path that produced the error or annotation. + +### Keyword Interactions + +Keyword behavior MAY be defined in terms of the annotation results of +[subschemas](#root) and/or adjacent keywords (keywords within the same schema +object) and their subschemas. Such keywords MUST NOT result in a circular +dependency. Keywords MAY modify their behavior based on the presence or absence +of another keyword in the same [schema object](#schema-document). + +### Default Behaviors {#default-behaviors} + +A missing keyword MUST NOT produce a false assertion result, MUST NOT produce +annotation results, and MUST NOT cause any other schema to be evaluated as part +of its own behavioral definition. However, given that missing keywords do not +contribute annotations, the lack of annotation results may indirectly change the +behavior of other keywords. + +In some cases, the missing keyword assertion behavior of a keyword is identical +to that produced by a certain value, and keyword definitions SHOULD note such +values where known. However, even if the value which produces the default +behavior would produce annotation results if present, the default behavior still +MUST NOT result in annotations. + +Because annotation collection can add significant cost in terms of both +computation and memory, implementations MAY opt out of this feature. Keywords +that are specified in terms of collected annotations SHOULD describe reasonable +alternate approaches when appropriate. This approach is demonstrated by the +[`items`](#items) and [`additionalProperties`](#additionalproperties) keywords +in this document. + +Note that when no such alternate approach is possible for a keyword, +implementations that do not support annotation collections will not be able to +support those keywords or vocabularies that contain them. + +### Identifiers + +Identifiers define IRIs for a schema, or affect how such IRIs are resolved in +[references](#referenced), or both. The Core vocabulary defined in this document +defines several identifying keywords, most notably `$id`. + +Canonical schema IRIs MUST NOT change while processing an instance, but keywords +that affect IRI-reference resolution MAY have behavior that is only fully +determined at runtime. + +While custom identifier keywords are possible, vocabulary designers should take +care not to disrupt the functioning of core keywords. For example, the +`$dynamicAnchor` keyword in this specification limits its IRI resolution effects +to the matching `$dynamicRef` keyword, leaving the behavior of `$ref` +undisturbed. + +### Applicators {#applicators} + +Applicators allow for building more complex schemas than can be accomplished +with a single schema object. Evaluation of an instance against a [schema +document](#schema-document) begins by applying the [root schema](#root) to the +complete instance document. From there, keywords known as applicators are used +to determine which additional schemas are applied. Such schemas may be applied +in-place to the current location, or to a child location. + +The schemas to be applied may be present as subschemas comprising all or part of +the keyword's value. Alternatively, an applicator may refer to a schema +elsewhere in the same schema document, or in a different one. The mechanism for +identifying such referenced schemas is defined by the keyword. + +Applicator keywords also define how subschema or referenced schema boolean +[assertion](#assertions) results are modified and/or combined to produce the +boolean result of the applicator. Applicators may apply any boolean logic +operation to the assertion results of subschemas, but MUST NOT introduce new +assertion conditions of their own. + +[Annotation](#annotations) results from subschemas are preserved in accordance +with {{collect}} so that applications can decide how to interpret multiple +values. Applicator keywords do not play a direct role in this preservation. + +#### Referenced and Referencing Schemas {#referenced} + +As noted in {{applicators}}, an applicator keyword may refer to a schema to be +applied, rather than including it as a subschema in the applicator's value. In +such situations, the schema being applied is known as the referenced schema, +while the schema containing the applicator keyword is the referencing schema. + +While root schemas and subschemas are static concepts based on a schema's +position within a schema document, referenced and referencing schemas are +dynamic. Different pairs of schemas may find themselves in various referenced +and referencing arrangements during the evaluation of an instance against a +schema. + +For some by-reference applicators, such as [`$ref`](#ref), the referenced schema +can be determined by static analysis of the schema document's lexical scope. +Others, such as `$dynamicRef` (with `$dynamicAnchor`), may make use of dynamic +scoping, and therefore only be resolvable in the process of evaluating the +schema with an instance. + +### Assertions {#assertions} + +JSON Schema can be used to assert constraints on a JSON document, which either +passes or fails the assertions. This approach can be used to validate +conformance with the constraints, or document what is needed to satisfy them. + +JSON Schema implementations produce a single boolean result when evaluating an +instance against schema assertions. + +An instance can only fail an assertion that is present in the schema. + +#### Assertions and Instance Primitive Types + +Most assertions only constrain values within a certain primitive type. When the +type of the instance is not of the type targeted by the keyword, the instance is +considered to conform to the assertion. + +For example, the `maxLength` keyword from the companion [validation +vocabulary](#json-schema-validation): will only restrict certain strings (that +are too long) from being valid. If the instance is a number, boolean, null, +array, or object, then it is valid against this assertion. + +This behavior allows keywords to be used more easily with instances that can be +of multiple primitive types. The companion validation vocabulary also includes a +`type` keyword which can independently restrict the instance to one or more +primitive types. This allows for a concise expression of use cases such as a +function that might return either a string of a certain length or a null value: + +```jsonschema +{ + "type": ["string", "null"], + "maxLength": 255 +} +``` + +If `maxLength` also restricted the instance type to be a string, then this would +be substantially more cumbersome to express because the example as written would +not actually allow null values. Each keyword is evaluated separately unless +explicitly specified otherwise, so if `maxLength` restricted the instance to +strings, then including `"null"` in `type` would not have any useful effect. + +### Annotations {#annotations} + +JSON Schema can annotate an instance with information, whenever the instance +validates against the schema object containing the annotation, and all of its +parent schema objects. The information can be a simple value, or can be +calculated based on the instance contents. + +Annotations are attached to specific locations in an instance. Since many +subschemas can be applied to any single location, applications may need to +decide how to handle differing annotation values being attached to the same +instance location by the same schema keyword in different schema objects. + +Unlike assertion results, annotation data can take a wide variety of forms, +which are provided to applications to use as they see fit. JSON Schema +implementations are not expected to make use of the collected information on +behalf of applications. + +Unless otherwise specified, the value of an annotation keyword is the keyword's +value. However, other behaviors are possible. For example, [JSON +Hyper-Schema's](#json-hyper-schema) `links` keyword is a complex annotation that +produces a value based in part on the instance data. + +While "short-circuit" evaluation is possible for assertions, collecting +annotations requires examining all schemas that apply to an instance location, +even if they cannot change the overall assertion result. The only exception is +that subschemas of a schema object that has failed validation MAY be skipped, as +annotations are not retained for failing schemas. + +#### Collecting Annotations {#collect} + +Annotations are collected by keywords that explicitly define +annotation-collecting behavior. Note that boolean schemas cannot produce +annotations as they do not make use of keywords. + +A collected annotation MUST include the following information: + +- The name of the keyword that produces the annotation +- The instance location to which it is attached, as a JSON Pointer +- The evaluation path, indicating how reference keywords such as `$ref` were + followed to reach the absolute schema location. +- The absolute schema location of the attaching keyword, as a IRI. This MAY be + omitted if it is the same as the evaluation path from above. +- The attached value(s) + +##### Distinguishing Among Multiple Values + +Applications MAY make decisions on which of multiple annotation values to use +based on the schema location that contributed the value. This is intended to +allow flexible usage. Collecting the schema location facilitates such usage. + +For example, consider this schema, which uses annotations and assertions from +the [Validation specification](#json-schema-validation): + +Note that some lines are wrapped for clarity. + +```jsonschema +{ + "title": "Feature list", + "type": "array", + "prefixItems": [ + { + "title": "Feature A", + "properties": { + "enabled": { + "$ref": "#/$defs/enabledToggle", + "default": true + } + } + }, + { + "title": "Feature B", + "properties": { + "enabled": { + "description": "If set to null, Feature B + inherits the enabled + value from Feature A", + "$ref": "#/$defs/enabledToggle" + } + } + } + ], + "$defs": { + "enabledToggle": { + "title": "Enabled", + "description": "Whether the feature is enabled (true), + disabled (false), or under + automatic control (null)", + "type": ["boolean", "null"], + "default": null + } + } +} +``` + +In this example, both Feature A and Feature B make use of the re-usable +"enabledToggle" schema. That schema uses the `title`, `description`, and +`default` annotations. Therefore the application has to decide how to handle the +additional `default` value for Feature A, and the additional `description` value +for Feature B. + +The application programmer and the schema author need to agree on the usage. For +this example, let's assume that they agree that the most specific `default` +value will be used, and any additional, more generic `default` values will be +silently ignored. Let's also assume that they agree that all `description` text +is to be used, starting with the most generic, and ending with the most +specific. This requires the schema author to write descriptions that work when +combined in this way. + +The application can use the evaluation path to determine which values are which. +The values in the feature's immediate "enabled" property schema are more +specific, while the values under the re-usable schema that is referenced to with +`$ref` are more generic. The evaluation path will show whether each value was +found by crossing a `$ref` or not. + +Feature A will therefore use a default value of true, while Feature B will use +the generic default value of null. Feature A will only have the generic +description from the "enabledToggle" schema, while Feature B will use that +description, and also append its locally defined description that explains how +to interpret a null value. + +Note that there are other reasonable approaches that a different application +might take. For example, an application may consider the presence of two +different values for `default` to be an error, regardless of their schema +locations. + +##### Annotations and Assertions {#annot-assert} + +Schema objects that produce a false assertion result MUST NOT produce any +annotation results, whether from their own keywords or from keywords in +subschemas. + +Note that the overall schema results may still include annotations collected +from other schema locations. Given this schema: + +```jsonschema +{ + "oneOf": [ + { + "title": "Integer Value", + "type": "integer" + }, + { + "title": "String Value", + "type": "string" + } + ] +} +``` + +Against the instance `"This is a string"`, the title annotation "Integer Value" +is discarded because the type assertion in that schema object fails. The title +annotation "String Value" is kept, as the instance passes the string type +assertions. + +### Reserved Locations + +A fourth category of keywords simply reserve a location to hold re-usable +components or data of interest to schema authors that is not suitable for +re-use. These keywords do not affect validation or annotation results. Their +purpose in the core vocabulary is to ensure that locations are available for +certain purposes and will not be redefined by extension keywords. + +While these keywords do not directly affect results, as explained in +{{non-schemas}} unrecognized extension keywords that reserve locations for +re-usable schemas may have undesirable interactions with references in certain +circumstances. + +### Loading Instance Data + +While none of the vocabularies defined as part of this or the associated +documents define a keyword which may target and/or load instance data, it is +possible that other vocabularies may wish to do so. + +Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to +examine parts of an instance outside the current evaluation location. + +Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD +default to using the current location if a default is desireable. + +## The JSON Schema Core Vocabulary {#core} + +Keywords declared in this section, which all begin with "$", make up the JSON +Schema Core vocabulary. These keywords are either required in order to process +any schema or meta-schema, including those split across multiple documents, or +exist to reserve keywords for purposes that require guaranteed interoperability. + +The Core vocabulary MUST be considered mandatory at all times, in order to +bootstrap the processing of further vocabularies. Meta-schemas that use the +[`$vocabulary`](#vocabulary) keyword to declare the vocabularies in use MUST +explicitly list the Core vocabulary, which MUST have a value of true indicating +that it is required. + +The behavior of a false value for this vocabulary (and only this vocabulary) is +undefined, as is the behavior when `$vocabulary` is present but the Core +vocabulary is not included. However, it is RECOMMENDED that implementations +detect these cases and raise an error when they occur. It is not meaningful to +declare that a meta-schema optionally uses Core. + +Meta-schemas that do not use `$vocabulary` MUST be considered to require the +Core vocabulary as if its IRI were present with a value of true. + +The current IRI for the Core vocabulary is: +`https://json-schema.org/draft/next/vocab/core`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/core`. + +The "$" prefix is reserved for use by the Core vocabulary. Vocabulary extensions +MUST NOT define new keywords that begin with "$". + +### Meta-Schemas and Vocabularies {#vocabulary} + +Two concepts, meta-schemas and vocabularies, are used to inform an +implementation how to interpret a schema. Every schema has a meta-schema, which +can be declared using the `$schema` keyword. + +The meta-schema serves two purposes: + +Declaring the vocabularies in use: The `$vocabulary` keyword, when it appears in +a meta-schema, declares which vocabularies are available to be used in schemas +that refer to that meta-schema. Vocabularies define keyword semantics, as well +as their general syntax. + +Describing valid schema syntax: A schema MUST successfully validate against its +meta-schema, which constrains the syntax of the available keywords. The syntax +described is expected to be compatible with the vocabularies declared; while it +is possible to describe an incompatible syntax, such a meta-schema would be +unlikely to be useful. + +Meta-schemas are separate from vocabularies to allow for vocabularies to be +combined in different ways, and for meta-schema authors to impose additional +constraints such as forbidding certain keywords, or performing unusually strict +syntactical validation, as might be done during a development and testing cycle. +Each vocabulary typically identifies a meta-schema consisting only of the +vocabulary's keywords. + +Meta-schema authoring is an advanced usage of JSON Schema, so the design of +meta-schema features emphasizes flexibility over simplicity. + +#### The `$schema` Keyword {#keyword-schema} + +The `$schema` keyword is both used as a JSON Schema dialect identifier and as +the identifier of a resource which is itself a JSON Schema, which describes the +set of valid schemas written for this particular dialect. + +The value of this keyword MUST be a [IRI](#rfc3987) (containing a scheme) and +this IRI MUST be normalized. The current schema MUST be valid against the +meta-schema identified by this IRI. + +If this IRI identifies a retrievable resource, that resource SHOULD be of media +type `application/schema+json`. + +The `$schema` keyword SHOULD be used in the document root schema object, and MAY +be used in the root schema objects of embedded schema resources. It MUST NOT +appear in non-resource root schema objects. If absent from the document root +schema, the resulting behavior is implementation-defined, but MUST fall within +the following options: + +- Refuse to process the schema, as with unsupported required vocabularies +- Assume a specific, documented meta-schema +- Document the process by which it examines the schema and determines which of a + specific set of meta-schemas to assume + +Values for this property are defined elsewhere in this and other documents, and +by other parties. + +#### The `$vocabulary` Keyword + +The `$vocabulary` keyword is used in meta-schemas to identify the vocabularies +available for use in schemas described by that meta-schema, and whether each +vocabulary is required or optional. Together, this information forms a dialect. + +The value of this keyword MUST be an object. The property names in the object +MUST be IRIs (containing a scheme) and each IRI MUST be normalized. Each IRI +that appears as a property name identifies a specific set of keywords and their +semantics. + +The IRI MAY be a URL, but the nature of the retrievable resource is currently +undefined, and reserved for future use. Vocabulary authors MAY use the URL of +the vocabulary specification, in a human-readable media type such as `text/html` +or `text/plain`, as the vocabulary IRI.[^2] + +[^2]: Vocabulary documents may be added in forthcoming drafts. For now, +identifying the keyword set is deemed sufficient as that, along with meta-schema +validation, is how the current "vocabularies" work today. Any future vocabulary +document format will be specified as a JSON document, so using `text/html` or +other non-JSON formats in the meantime will not produce any future ambiguity. + +The values of the object properties MUST be booleans. If the value is true, then +the vocabulary MUST be considered to be required. If the value is false, then +the vocabulary MUST be considered to be optional. + +##### Required, optional, and omitted vocabularies + +A schema is said to use a dialect and its constituent vocabularies if it is +associated with a meta-schema defining the dialect with `$vocabulary`, either +through `$schema`, through appropriately defined media type parameters or link +relation types, or through documented default implementation-defined behavior in +the absence of an explicit meta-schema. If a meta-schema does not contain +`$vocabulary`, the set of vocabularies in use is determined according to +{{default-vocabs}}. + +Any vocabulary in use by a schema and understood by the implementation MUST be +processed in a manner consistent with the semantic definitions contained within +the vocabulary, regardless of whether that vocabulary is required or optional. + +Any vocabulary that is not present in `$vocabulary` MUST NOT be made available +for use in schemas described by that meta-schema, except for the core vocabulary +as specified by the introduction to {{core}}. + +Implementations that do not support a vocabulary required by a schema MUST +refuse to process that schema. + +Implementations that do not support a vocabulary that is optionally used by a +schema SHOULD proceed with processing the schema. The keywords will be +considered to be unrecognized keywords as addressed by {{unrecognized}}. Note +that since the recommended behavior for such keywords is to collect them as +annotations, vocabularies consisting only of annotations will have the same +behavior when used optionally whether the implementation supports them or not. +This allows annotation-only vocabularies to be supported without custom code, +even in implementations that do not support providing custom code for extension +vocabularies. + +##### Vocabularies are schema resource-scoped + +The `$vocabulary` keyword SHOULD be used in the root schema of any schema +resource intended for use as a meta-schema. It MUST NOT appear in subschemas. + +The `$vocabulary` keyword MUST be ignored in schema resources that are not being +processed as a meta-schema. This allows validating a meta-schema M against its +own meta-schema M' without requiring the validator to understand the +vocabularies declared by M. + +##### Vocabulary and non-vocabulary keywords + +Keywords from different vocabularies, as well as non-vocabulary extension +keywords, can have identical names. These are not considered to be the same +keyword from the perspective of enabling or disabling them through +`$vocabulary`. + +In particular the keywords defined in this specification and its companion +documents MUST be considered to be vocabulary keywords, with availability +governed by `$vocabulary` even in implementations that do not support any +extension vocabularies. + +Guidance regarding vocabularies with identically-named keywords is provided in +{{vocab-practices}}. + +##### Default vocabularies {#default-vocabs} + +If `$vocabulary` is absent, an implementation MAY determine behavior based on +the meta-schema if it is recognized from the IRI value of the referring schema's +`$schema` keyword. This is how behavior (such as Hyper-Schema usage) has been +recognized prior to the existence of vocabularies. + +If the meta-schema, as referenced by the schema, is not recognized, or is +missing, then the behavior is implementation-defined. If the implementation +proceeds with processing the schema, it MUST assume the use of the core +vocabulary. If the implementation is built for a specific purpose, then it +SHOULD assume the use of all of the most relevant vocabularies for that purpose. + +For example, an implementation that is a validator SHOULD assume the use of all +vocabularies in this specification and the companion Validation specification. + +##### Non-inheritability of vocabularies + +Note that the processing restrictions on `$vocabulary` mean that meta-schemas +that reference other meta-schemas using `$ref` or similar keywords do not +automatically inherit the vocabulary declarations of those other meta-schemas. +All such declarations must be repeated in the root of each schema document +intended for use as a meta-schema. This is demonstrated in [the example +meta-schema](#example-meta-schema).[^3] + +[^3]: This requirement allows implementations to find all vocabulary requirement +information in a single place for each meta-schema. As schema extensibility +means that there are endless potential ways to combine more fine-grained +meta-schemas by reference, requiring implementations to anticipate all +possibilities and search for vocabularies in referenced meta-schemas would be +overly burdensome. + +#### Updates to Meta-Schema and Vocabulary IRIs + +Updated vocabulary and meta-schema IRIs MAY be published between specification +drafts in order to correct errors. Implementations SHOULD consider IRIs dated +after this specification draft and before the next to indicate the same syntax +and semantics as those listed here. + +### Base IRI, Anchors, and Dereferencing + +To differentiate between schemas in a vast ecosystem, schemas are identified by +[IRI](#rfc3987), and can embed references to other schemas by specifying their +IRI. + +Several keywords can accept a relative [IRI-reference](#rfc3987), or a value +used to construct a relative IRI-reference. For these keywords, it is necessary +to establish a base IRI in order to resolve the reference. + +#### The `$id` Keyword {#id-keyword} + +The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) +IRI. + +Note that this IRI is an identifier and not necessarily a network locator. In +the case of a network-addressable URL, a schema need not be downloadable from +its canonical IRI. + +If present, the value for this keyword MUST be a string, and MUST represent a +valid [IRI-reference](#rfc3987). This IRI-reference SHOULD be normalized, and +MUST resolve to an [absolute-IRI](#rfc3987) (without a fragment). + +The resulting absolute-IRI serves as the base IRI for relative IRI-references in +keywords within the schema resource, in accordance with [RFC 3987 section +6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs +embedded in content. + +The presence of `$id` in a subschema indicates that the subschema constitutes a +distinct schema resource within a single schema document. Furthermore, in +accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section +5.1.2](#rfc3986) regarding encapsulating entities, if an `$id` in a subschema is +a relative IRI-reference, the base IRI for resolving that reference is the IRI +of the parent schema resource. Note that an `$id` consisting of an empty IRI or +of the empty fragment only will result in the embedded resource having the same +IRI as the encapsulating resource, which SHOULD be considered an error per +{{duplicate-iris}}. + +If no parent schema object explicitly identifies itself as a resource with +`$id`, the base IRI is that of the entire document, as established by the steps +given in the [previous section.](initial-base) + +##### Identifying the root schema + +The root schema of a JSON Schema document SHOULD contain an `$id` keyword with +an [absolute-IRI](#rfc3987) (containing a scheme, but no fragment). + +#### Defining location-independent identifiers {#anchors} + +Using JSON Pointer fragments requires knowledge of the structure of the schema. +When writing schema documents with the intention to provide re-usable schemas, +it may be preferable to use a plain name fragment that is not tied to any +particular structural location. This allows a subschema to be relocated without +requiring JSON Pointer references to be updated. + +The `$anchor` and `$dynamicAnchor` keywords are used to specify such fragments. +They are identifier keywords that can only be used to create plain name +fragments, rather than absolute IRIs as seen with `$id`. + +The base IRI to which the resulting fragment is appended is the canonical IRI of +the schema resource containing the `$anchor` or `$dynamicAnchor` in question. +As discussed in the previous section, this is either the nearest `$id` in the +same or parent schema object, or the base IRI for the document as determined +according to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). + +Separately from the usual usage of IRIs, `$dynamicAnchor` indicates that the +fragment is an extension point when used with the `$dynamicRef` keyword. This +low-level, advanced feature makes it easier to extend recursive schemas such as +the meta-schemas, without imposing any particular semantics on that extension. +See the section on [`$dynamicRef`](#dynamic-ref) for details. + +In most cases, the normal fragment behavior both suffices and is more intuitive. +Therefore it is RECOMMENDED that `$anchor` be used to create plain name +fragments unless there is a clear need for `$dynamicAnchor`. + +If present, the value of these keywords MUST be a string and MUST conform to the +plain name fragment identifier syntax defined in {{fragments}}.[^4] + +[^4]: Note that the anchor string does not include the "#" character, as it is +not a IRI-reference. An `$anchor`: "foo" becomes the fragment `#foo` when used +in a IRI. See below for full examples. + +#### Duplicate schema identifiers {#duplicate-iris} + +A schema MAY (and likely will) have multiple IRIs, but there is no way for an +IRI to identify more than one schema. When multiple schemas attempt to identify +as the same IRI through the use of `$id`, `$anchor`, `$dynamicAnchor`, or any +other mechanism, implementations SHOULD raise an error condition. Otherwise the +result is undefined, and even if documented will not be interoperable. + +#### Schema References {#references} + +Several keywords can be used to reference a schema which is to be applied to the +current instance location. `$ref` and `$dynamicRef` are applicator keywords, +applying the referenced schema to the instance. + +As the values of `$ref` and `$dynamicRef` are IRI References, this allows the +possibility to externalise or divide a schema across multiple files, and +provides the ability to validate recursive structures through self-reference. + +The resolved IRI produced by these keywords is not necessarily a network +locator, only an identifier. A schema need not be downloadable from the address +if it is a network-addressable URL, and implementations SHOULD NOT assume they +should perform a network operation when they encounter a network-addressable +IRI. + +##### Direct References with `$ref` {#ref} + +The `$ref` keyword is an applicator that is used to reference a statically +identified schema. Its results are the results of the referenced schema.[^5] + +[^5]: Note that this definition of how the results are determined means that +other keywords can appear alongside of `$ref` in the same schema object. + +The value of the `$ref` keyword MUST be a string which is a IRI-Reference. +Resolved against the current IRI base, it produces the IRI of the schema to +apply. This resolution is safe to perform on schema load, as the process of +evaluating an instance cannot change how the reference resolves. + +##### Dynamic References with `$dynamicRef` {#dynamic-ref} + +The `$dynamicRef` keyword is an applicator that allows for deferring the full +resolution until runtime, at which point it is resolved each time it is +encountered while evaluating an instance. + +Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension +mechanism that is primarily useful with recursive schemas (schemas that +reference themselves). The extension point is defined with `$dynamicAnchor` and +only exhibits runtime dynamic behavior when referenced with `$dynamicRef`. + +The value of the `$dynamicRef` property MUST be a string which is a +IRI-Reference that contains a valid [plain name fragment](#anchors). Resolved +against the current IRI base, it indicates the schema resource used as the +starting point for runtime resolution. This initial resolution is safe to +perform on schema load. + +The schema to apply is the outermost schema resource in the [dynamic +scope](#scopes) that defines a `$dynamicAnchor` that matches the plain name +fragment in the initially resolved IRI. + +For a full example using these keyword, see {{recursive-example}}.[^6] + +[^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and +an this draft dramatically demonstrates the utility of these keywords. + +#### Schema Re-Use With `$defs` {#defs} + +The `$defs` keyword reserves a location for schema authors to inline re-usable +JSON Schemas into a more general schema. The keyword does not directly affect +the validation result. + +This keyword's value MUST be an object. Each member value of this object MUST be +a valid JSON Schema. + +As an example, here is a schema describing an array of positive integers, where +the positive integer constraint is a subschema in `$defs`: + +```jsonschema +{ + "type": "array", + "items": { "$ref": "#/$defs/positiveInteger" }, + "$defs": { + "positiveInteger": { + "type": "integer", + "exclusiveMinimum": 0 + } + } +} +``` + +### Comments With `$comment` + +This keyword reserves a location for comments from schema authors to readers or +maintainers of the schema. + +The value of this keyword MUST be a string. Implementations MUST NOT present +this string to end users. Tools for editing schemas SHOULD support displaying +and editing this keyword. The value of this keyword MAY be used in debug or +error output which is intended for developers making use of schemas. + +Schema vocabularies SHOULD allow `$comment` within any object containing +vocabulary keywords. Implementations MAY assume `$comment` is allowed unless the +vocabulary specifically forbids it. Vocabularies MUST NOT specify any effect of +`$comment` beyond what is described in this specification. + +Tools that translate other media types or programming languages to and from +`application/schema+json` MAY choose to convert that media type or programming +language's native comments to or from `$comment` values. The behavior of such +translation when both native comments and `$comment` properties are present is +implementation-dependent. + +Implementations MAY strip `$comment` values at any point during processing. In +particular, this allows for shortening schemas when the size of deployed schemas +is a concern. + +Implementations MUST NOT take any other action based on the presence, absence, +or contents of `$comment` properties. In particular, the value of `$comment` +MUST NOT be collected as an annotation result. + +## Loading and Processing Schemas + +### Loading a Schema + +#### Initial Base IRI {#initial-base} + +[RFC 3987 Section 6.5](#rfc3987) and [RFC 3986 Section 5.1](#rfc3986) defines +how to determine the default base IRI of a document. + +Informatively, the initial base IRI of a schema is the IRI at which it was +found, whether that was a network location, a local filesystem, or any other +situation identifiable by a IRI of any known scheme. + +If a schema document defines no explicit base IRI with `$id` (embedded in +content), the base IRI is that determined per [RFC 3987 Section 6.5](#rfc3987) +and [RFC 3986 section 5](#rfc3986). + +If no source is known, or no IRI scheme is known for the source, a suitable +implementation-specific default IRI MAY be used as described in [RFC 3987 +Section 6.5](#rfc3987) and [RFC 3986 Section 5.1.4](#rfc3986). It is RECOMMENDED +that implementations document any default base IRI that they assume. + +If a schema object is embedded in a document of another media type, then the +initial base IRI is determined according to the rules of that media type. + +Unless the `$id` keyword described in an earlier section is present in the root +schema, this base IRI SHOULD be considered the canonical IRI of the schema +document's root schema resource. + +#### Loading a referenced schema + +The use of IRIs to identify remote schemas does not necessarily mean anything is +downloaded, but instead JSON Schema implementations SHOULD understand ahead of +time which schemas they will be using, and the IRIs that identify them. + +When schemas are downloaded, for example by a generic user-agent that does not +know until runtime which schemas to download, see [Usage for +Hypermedia](#hypermedia). + +Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary +schema and/or automatically associate a schema's `$id`-given IRI, depending on +the trust that the validator has in the schema. Such IRIs and schemas can be +supplied to an implementation prior to processing instances, or may be noted +within a schema document as it is processed, producing associations as shown in +{{idexamples}}. + +#### Detecting a Meta-Schema + +Implementations MUST recognize a schema as a meta-schema if it is being examined +because it was identified as such by another schema's `$schema` keyword. This +means that a single schema document might sometimes be considered a regular +schema, and other times be considered a meta-schema. + +In the case of examining a schema which is its own meta-schema, when an +implementation begins processing it as a regular schema, it is processed under +those rules. However, when loaded a second time as a result of checking its own +`$schema` value, it is treated as a meta-schema. So the same document is +processed both ways in the course of one session. + +Implementations MAY allow a schema to be explicitly passed as a meta-schema, for +implementation-specific purposes, such as pre-loading a commonly used +meta-schema and checking its vocabulary support requirements up front. +Meta-schema authors MUST NOT expect such features to be interoperable across +implementations. + +### Dereferencing + +Schemas can be identified by any IRI that has been given to them, including a +JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing a +`$ref` reference involves first resolving its value as a IRI reference against +the current base IRI per [RFC 3986](#rfc3986). + +If the resulting IRI identifies a schema within the current document, or within +another schema document that has been made available to the implementation, then +that schema SHOULD be used automatically. + +For example, consider this schema: + +```jsonschema +{ + "$id": "https://example.net/root.json", + "type": "array", + "items": { "$ref": "#item" }, + "$defs": { + "single": { + "$anchor": "item", + "type": "object", + "additionalProperties": { "$ref": "other.json" } + } + } +} +``` + +When an implementation encounters the `#/$defs/single` schema, it resolves the +`$anchor` value as a fragment name against the current base IRI to form +`https://example.net/root.json#item`. + +When an implementation then looks inside the `#/items` schema, it encounters the +`#item` reference, and resolves this to `https://example.net/root.json#item`, +which it has seen defined in this same document and can therefore use +automatically. + +When an implementation encounters the reference to "other.json", it resolves +this to `https://example.net/other.json`, which is not defined in this document. +If a schema with that identifier has otherwise been supplied to the +implementation, it can also be used automatically.[^7] + +[^7]: What should implementations do when the referenced schema is not known? +Are there circumstances in which automatic network dereferencing is allowed? A +same origin policy? A user-configurable option? In the case of an evolving API +described by Hyper-Schema, it is expected that new schemas will be added to the +system dynamically, so placing an absolute requirement of pre-loading schema +documents is not feasible. + +#### JSON Pointer fragments and embedded schema resources {#embedded} + +Since JSON Pointer IRI fragments are constructed based on the structure of the +schema document, an embedded schema resource and its subschemas can be +identified by JSON Pointer fragments relative to either its own canonical IRI, +or relative to any containing resource's IRI. + +Conceptually, a set of linked schema resources should behave identically whether +each resource is a separate document connected with [schema +references](#referenced), or is structured as a single document with one or more +schema resources embedded as subschemas. + +Since IRIs involving JSON Pointer fragments relative to the parent schema +resource's IRI cease to be valid when the embedded schema is moved to a separate +document and referenced, applications and schemas SHOULD NOT use such IRIs to +identify embedded schema resources or locations within them. + +Consider the following schema document that contains another schema resource +embedded within it: + +```jsonschema +{ + "$id": "https://example.com/foo", + "items": { + "$id": "https://example.com/bar", + "additionalProperties": { } + } +} +``` + +The IRI `https://example.com/foo#/items` points to the `items` schema, which is +an embedded resource. The canonical IRI of that schema resource, however, is +`https://example.com/bar`. + +For the `additionalProperties` schema within that embedded resource, the IRI +`https://example.com/foo#/items/additionalProperties` points to the correct +object, but that object's IRI relative to its resource's canonical IRI is +`https://example.com/bar#/additionalProperties`. + +Now consider the following two schema resources linked by reference using a IRI +value for `$ref`: + +```jsonschema +{ + "$id": "https://example.com/foo", + "items": { + "$ref": "bar" + } +} +``` + +```jsonschema +{ + "$id": "https://example.com/bar", + "additionalProperties": {} +} +``` + +Here we see that `https://example.com/bar#/additionalProperties`, using a JSON +Pointer fragment appended to the canonical IRI of the "bar" schema resource, is +still valid, while `https://example.com/foo#/items/additionalProperties`, which +relied on a JSON Pointer fragment appended to the canonical IRI of the "foo" +schema resource, no longer resolves to anything. + +Note also that `https://example.com/foo#/items` is valid in both arrangements, +but resolves to a different value. This IRI ends up functioning similarly to a +retrieval IRI for a resource. While this IRI is valid, it is more robust to use +the `$id` of the embedded or referenced resource unless it is specifically +desired to identify the object containing the `$ref` in the second +(non-embedded) arrangement. + +An implementation MAY choose not to support addressing schema resource contents +by IRIs using a base other than the resource's canonical IRI, plus a JSON +Pointer fragment relative to that base. Therefore, schema authors SHOULD NOT +rely on such IRIs, as using them may reduce interoperability.[^8] + +[^8]: This is to avoid requiring implementations to keep track of a whole stack +of possible base IRIs and JSON Pointer fragments for each, given that all but +one will be fragile if the schema resources are reorganized. Some have argued +that this is easy so there is no point in forbidding it, while others have +argued that it complicates schema identification and should be forbidden. +Feedback on this topic is encouraged. After some discussion, we feel that we +need to remove the use of "canonical" in favour of talking about JSON Pointers +which reference across schema resource boundaries as undefined or even forbidden +behavior (, +) + +Further examples of such non-canonical IRI construction, as well as the +appropriate canonical IRI-based fragments to use instead, are provided in +{{idexamples}}. + +### Compound Documents + +A Compound Schema Document is defined as a JSON document (sometimes called a +"bundled" schema) which has multiple embedded JSON Schema Resources bundled into +the same document to ease transportation. + +Each embedded Schema Resource MUST be treated as an individual Schema Resource, +following standard schema loading and processing requirements, including +determining vocabulary support. + +#### Bundling + +The bundling process for creating a Compound Schema Document is defined as +taking references (such as `$ref`) to an external Schema Resource and embedding +the referenced Schema Resources within the referring document. Bundling SHOULD +be done in such a way that all IRIs (used for referencing) in the base document +and any referenced/embedded documents do not require altering. + +Each embedded JSON Schema Resource MUST identify itself with a IRI using the +`$id` keyword, and SHOULD make use of the `$schema` keyword to identify the +dialect it is using, in the root of the schema resource. It is RECOMMENDED that +the IRI identifier value of `$id` be an Absolute IRI. + +When the Schema Resource referenced by a by-reference applicator is bundled, it +is RECOMMENDED that the Schema Resource be located as a value of a `$defs` +object at the containing schema's root. The key of the `$defs` for the now +embedded Schema Resource MAY be the `$id` of the bundled schema or some other +form of application defined unique identifer (such as a UUID). This key is not +intended to be referenced in JSON Schema, but may be used by an application to +aid the bundling process. + +A Schema Resource MAY be embedded in a location other than `$defs` where the +location is defined as a schema value. + +A Bundled Schema Resource MUST NOT be bundled by replacing the schema object +from which it was referenced, or by wrapping the Schema Resource in other +applicator keywords. + +In order to produce identical output, references in the containing schema +document to the previously external Schema Resources MUST NOT be changed, and +now resolve to a schema using the `$id` of an embedded Schema Resource. Such +identical output includes validation evaluation and IRIs or paths used in +resulting annotations or errors. + +While the bundling process will often be the main method for creating a Compound +Schema Document, it is also possible and expected that some will be created by +hand, potentially without individual Schema Resources existing on their own +previously. + +#### Differing and Default Dialects + +When multiple schema resources are present in a single document, schema +resources which do not define with which dialect they should be processed MUST +be processed with the same dialect as the enclosing resource. + +Since any schema that can be referenced can also be embedded, embedded schema +resources MAY specify different processing dialects using the `$schema` values +from their enclosing resource. + +#### Validating + +Given that a Compound Schema Document may have embedded resources which identify +as using different dialects, these documents SHOULD NOT be validated by applying +a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED +that an alternate validation process be provided in order to validate Schema +Documents. Each Schema Resource SHOULD be separately validated against its +associated meta-schema.[^9] + +[^9]: If you know a schema is what's being validated, you can identify if the +schemas is a Compound Schema Document or not, by way of use of `$id`, which +identifies an embedded resource when used not at the document's root. + +A Compound Schema Document in which all embedded resources identify as using the +same dialect, or in which `$schema` is omitted and therefore defaults to that of +the enclosing resource, MAY be validated by applying the appropriate +meta-schema. + +### Caveats + +#### Guarding Against Infinite Recursion + +A schema MUST NOT be run into an infinite loop against an instance. For example, +if two schemas `#alice` and `#bob` both have an `allOf` property that refers to +the other, a naive validator might get stuck in an infinite recursive loop +trying to validate the instance. Schemas SHOULD NOT make use of infinite +recursive nesting like this; the behavior is undefined. + +#### References to Possible Non-Schemas {#non-schemas} + +Subschema objects (or booleans) are recognized by their use with known +applicator keywords or with location-reserving keywords such as [`$defs`](#defs) +that take one or more subschemas as a value. These keywords may be `$defs` and +the standard applicators from this document, or extension keywords from a known +vocabulary, or implementation-specific custom keywords. + +Multi-level structures of unknown keywords are capable of introducing nested +subschemas, which would be subject to the processing rules for `$id`. Therefore, +having a reference target in such an unrecognized structure cannot be reliably +implemented, and the resulting behavior is undefined. Similarly, a reference +target under a known keyword, for which the value is known not to be a schema, +results in undefined behavior in order to avoid burdening implementations with +the need to detect such targets.[^10] + +[^10]: These scenarios are analogous to fetching a schema over HTTP but +receiving a response with a Content-Type other than `application/schema+json`. +An implementation can certainly try to interpret it as a schema, but the origin +server offered no guarantee that it actually is any such thing. Therefore, +interpreting it as such has security implication and may produce unpredictable +results. + +Note that single-level custom keywords with identical syntax and semantics to +`$defs` do not allow for any intervening `$id` keywords, and therefore will +behave correctly under implementations that attempt to use any reference target +as a schema. However, this behavior is implementation-specific and MUST NOT be +relied upon for interoperability. + +### Associating Instances and Schemas + +#### Usage for Hypermedia {#hypermedia} + +JSON has been adopted widely by HTTP servers for automated APIs and robots. This +section describes how to enhance processing of JSON documents in a more RESTful +manner when used with protocols that support media types and [Web +linking](#rfc8288). + +##### Linking to a Schema + +It is RECOMMENDED that instances described by a schema provide a link to a +downloadable JSON Schema using the link relation "describedby", as defined by +[Linked Data Protocol 1.0, section 8.1](#w3crec-ldp-20150226). + +In HTTP, such links can be attached to any response using the [Link +header](#rfc8288). An example of such a header would be: + +``` +Link: ; rel="describedby" +``` + +##### Usage Over HTTP + +When used for hypermedia systems over a network, [HTTP](#rfc7231) is frequently +the protocol of choice for distributing schemas. Misbehaving clients can pose +problems for server maintainers if they pull a schema over the network more +frequently than necessary, when it's instead possible to cache a schema for a +long period of time. + +HTTP servers SHOULD set long-lived caching headers on JSON Schemas. HTTP clients +SHOULD observe caching headers and not re-request documents within their +freshness period. Distributed systems SHOULD make use of a shared cache and/or +caching proxy. + +Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema +implementation or software product. Since symbols are listed in decreasing order +of significance, the JSON Schema library name/version should precede the more +generic HTTP library name (if any). For example: + +``` +User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 +``` + +Clients SHOULD be able to make requests with a "From" header so that server +operators can contact the owner of a potentially misbehaving script. + +## A Vocabulary for Applying Subschemas + +This section defines a vocabulary of applicator keywords that are RECOMMENDED +for use as the basis of other vocabularies. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Applicator vocabulary, is: +`https://json-schema.org/draft/next/vocab/applicator`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/applicator`. + +### Keyword Independence + +Schema keywords typically operate independently, without affecting each other's +outcomes. + +For schema author convenience, there are some exceptions among the keywords in +this vocabulary: + +- `additionalProperties`, whose behavior is defined in terms of `properties` and + `patternProperties` +- `items`, whose behavior is defined in terms of `prefixItems` +- `contains`, whose behavior is affected by the presence and value of + `minContains` + +### Keywords for Applying Subschemas in Place {#in-place} + +These keywords apply subschemas to the same location in the instance as the +parent schema is being applied. They allow combining or modifying the subschema +results in various ways. + +Subschemas of these keywords evaluate the instance completely independently such +that the results of one such subschema MUST NOT impact the results of sibling +subschemas. Therefore subschemas may be applied in any order. + +#### Keywords for Applying Subschemas With Logic {#logic} + +These keywords correspond to logical operators for combining or modifying the +boolean assertion results of the subschemas. They have no direct impact on +annotation collection, although they enable the same annotation keyword to be +applied to an instance location with different values. Annotation keywords +define their own rules for combining such values. + +##### `allOf` {#allof} + +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against all schemas defined by this keyword's value. + +##### `anyOf` + +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against at least one schema defined by this keyword's value. Note +that when annotations are being collected, all subschemas MUST be examined so +that annotations are collected from each subschema that validates successfully. + +##### `oneOf` + +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against exactly one schema defined by this keyword's value. + +##### `not` {#not} + +This keyword's value MUST be a valid JSON Schema. + +An instance is valid against this keyword if it fails to validate successfully +against the schema defined by this keyword. + +#### Keywords for Applying Subschemas Conditionally {#conditional} + +Three of these keywords work together to implement conditional application of a +subschema based on the outcome of another subschema. The fourth is a shortcut +for a specific conditional case. + +`if`, `then`, and `else` MUST NOT interact with each other across subschema +boundaries. In other words, an `if` in one branch of an `allOf` MUST NOT have an +impact on a `then` or `else` in another branch. + +There is no default behavior for `if`, `then`, or `else` when they are not +present. In particular, they MUST NOT be treated as if present with an empty +schema, and when `if` is not present, both `then` and `else` MUST be entirely +ignored. + +##### `if` + +This keyword's value MUST be a valid JSON Schema. + +This validation outcome of this keyword's subschema has no direct effect on the +overall validation result. Rather, it controls which of the `then` or `else` +keywords are evaluated. + +Instances that successfully validate against this keyword's subschema MUST also +be valid against the subschema value of the `then` keyword, if present. + +Instances that fail to validate against this keyword's subschema MUST also be +valid against the subschema value of the `else` keyword, if present. + +If [annotations](#annotations) are being collected, they are collected from this +keyword's subschema in the usual way, including when the keyword is present +without either `then` or `else`. + +##### `then` + +This keyword's value MUST be a valid JSON Schema. + +When `if` is present, and the instance successfully validates against its +subschema, then validation succeeds against this keyword if the instance also +successfully validates against this keyword's subschema. + +This keyword has no effect when `if` is absent, or when the instance fails to +validate against its subschema. Implementations MUST NOT evaluate the instance +against this keyword, for either validation or annotation collection purposes, +in such cases. + +##### `else` + +This keyword's value MUST be a valid JSON Schema. + +When `if` is present, and the instance fails to validate against its subschema, +then validation succeeds against this keyword if the instance successfully +validates against this keyword's subschema. + +This keyword has no effect when `if` is absent, or when the instance +successfully validates against its subschema. Implementations MUST NOT evaluate +the instance against this keyword, for either validation or annotation +collection purposes, in such cases. + +##### `dependentSchemas` + +This keyword specifies subschemas that are evaluated if the instance is an +object and contains a certain property. + +This keyword's value MUST be an object. Each value in the object MUST be a valid +JSON Schema. + +If the object key is a property in the instance, the entire instance must +validate against the subschema. Its use is dependent on the presence of the +property. + +Omitting this keyword has the same behavior as an empty object. + +##### `propertyDependencies` + +This keyword specifies subschemas that are evaluated if the instance is an +object and contains a certain property with a certain string value. + +This keyword's value MUST be an object. Each value in the object MUST be an +object whose values MUST be valid JSON Schemas. + +If the outer object key is a property in the instance and the inner object key +is equal to the value of that property, the entire instance must validate +against the schema. Its use is dependent on the presence and value of the +property. + +Omitting this keyword has the same behavior as an empty object. + +### Keywords for Applying Subschemas to Child Instances + +Each of these keywords defines a rule for applying its subschema(s) to child +instances, specifically object properties and array items, and combining their +results. + +#### Keywords for Applying Subschemas to Arrays + +##### `prefixItems` + +The value of "prefixItems` MUST be a non-empty array of valid JSON Schemas. + +Validation succeeds if each element of the instance validates against the +subschema at the same position, if any. This keyword does not constrain the +length of the array. Only array positions present in both the keyword's value +and the instance value are affected by this keyword. + +This keyword produces an annotation value which is the largest index to which +this keyword applied a subschema. The value MAY be a boolean true if a subschema +was applied to every index of the instance, such as is produced by the `items` +keyword. This annotation affects the behavior of `items` and `unevaluatedItems`. + +Omitting this keyword has the same assertion behavior as an empty array. + +##### `items` {#items} + +The value of `items` MUST be a valid JSON Schema. + +This keyword applies its subschema to all instance elements at indexes greater +than the length of the `prefixItems` array in the same schema object, as +reported by the annotation result of that `prefixItems` keyword. If no such +annotation result exists, `items` applies its subschema to all instance array +elements.[^11] + +[^11]: Note that the behavior of `items` without `prefixItems` is identical to +that of the schema form of `items` in prior drafts. When `prefixItems` is +present, the behavior of `items` is identical to the former `additionalItems` +keyword. + +If the `items` subschema is applied to any positions within the instance array, +it produces an annotation result of boolean true, indicating that all remaining +array elements have been evaluated against this keyword's subschema. This +annotation affects the behavior of `unevaluatedItems` in the Unevaluated +vocabulary. + +Omitting this keyword has the same assertion behavior as an empty schema. + +Implementations MAY choose to implement or optimize this keyword in another way +that produces the same effect, such as by directly checking for the presence and +size of a `prefixItems` array. Implementations that do not support annotation +collection MUST do so. + +#### Keywords for Applying Subschemas to Objects + +##### `properties` + +The value of `properties` MUST be an object. Each value of this object MUST be a +valid JSON Schema. + +Validation succeeds if, for each name that appears in both the instance and as a +name within this keyword's value, the child instance for that name successfully +validates against the corresponding schema. + +The annotation result of this keyword is the set of instance property names +which are also present under this keyword. This annotation affects the behavior +of `additionalProperties` (in this vocabulary) and `unevaluatedProperties` in +the Unevaluated vocabulary. + +Omitting this keyword has the same assertion behavior as an empty object. + +##### `patternProperties` + +The value of `patternProperties` MUST be an object. Each property name of this +object SHOULD be a valid regular expression, according to the ECMA-262 regular +expression dialect. Each property value of this object MUST be a valid JSON +Schema. + +Validation succeeds if, for each instance name that matches any regular +expressions that appear as a property name in this keyword's value, the child +instance for that name successfully validates against each schema that +corresponds to a matching regular expression. Recall: regular expressions are +not implicitly anchored. + +The annotation result of this keyword is the set of instance property names +matched by at least one property under this keyword. This annotation affects the +behavior of `additionalProperties` (in this vocabulary) and +`unevaluatedProperties` (in the Unevaluated vocabulary). + +Omitting this keyword has the same assertion behavior as an empty object. + +##### `additionalProperties` {#additionalproperties} + +The value of `additionalProperties` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the presence and annotation results of +`properties` and `patternProperties` within the same schema object. Validation +with `additionalProperties` applies only to the child values of instance names +that do not appear in the annotation results of either `properties` or +`patternProperties`. + +For all such properties, validation succeeds if the child instance validates +against the `additionalProperties` schema. + +The annotation result of this keyword is the set of instance property names +validated by this keyword's subschema. This annotation affects the behavior of +`unevaluatedProperties` in the Unevaluated vocabulary. + +Omitting this keyword has the same assertion behavior as an empty schema. + +Implementations MAY choose to implement or optimize this keyword in another way +that produces the same effect, such as by directly checking the names in +`properties` and the patterns in `patternProperties` against the instance +property set. Implementations that do not support annotation collection MUST do +so.[^12] + +[^12]: In defining this option, it seems there is the potential for ambiguity in +the output format. The ambiguity does not affect validation results, but it does +affect the resulting output format. The ambiguity allows for multiple valid +output results depending on whether annotations are used or a solution that +"produces the same effect" as draft-07. It is understood that annotations from +failing schemas are dropped. See our [Decision +Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) +for further details. + +##### `propertyNames` + +The value of `propertyNames` MUST be a valid JSON Schema. + +If the instance is an object, this keyword validates if every property name in +the instance validates against the provided schema. Note the property name that +the schema is testing will always be a string. + +Omitting this keyword has the same behavior as an empty schema. + +#### Other Keywords for Applying Subschemas + +##### `maxContains` + +The value of this keyword MUST be a non-negative integer. + +This keyword modifies the behavior of `contains` within the same schema object, +as described below in the section for that keyword. + +Validation MUST always succeed against this keyword. The value of this keyword +is used as its annotation result. + +##### `minContains` + +The value of this keyword MUST be a non-negative integer. + +This keyword modifies the behavior of `contains` within the same schema object, +as described below in the section for that keyword. + +Validation MUST always succeed against this keyword. The value of this keyword +is used as its annotation result. + +Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. +However, as described in the section for `contains`, the absence of this +keyword's annotation causes `contains` to assume a minimum value of 1. + +##### `contains` + +The value of this keyword MUST be a valid JSON Schema. + +This keyword applies its subschema to array elements or object property values. + +An instance is valid against `contains` if the number of elements or property +values that are valid against its subschema is with the inclusive range of the +minimum and (if any) maximum number of occurrences. + +The maximum number of occurrences is provided by the `maxContains` keyword +within the same schema object as `contains`. If `maxContains` is absent, the +maximum number of occurrences MUST be unbounded. + +The minimum number of occurrences is provided by the `minContains` keyword +within the same schema object as `contains`. If `minContains` is absent, the +minimum number of occurrences MUST be 1. + +Implementations MAY implement the dependency on `minContians` and `maxContains` +by inspecting their values rather than reading annotations produced by those +keywords. + +This keyword produces an annotation value which is an array of the indexes or +property names to which this keyword validates successfully when applying its +subschema, in ascending order. The value MAY be a boolean `true` if the +subschema validates successfully when applied to every index or property value +of the instance. The annotation MUST be present if the instance array or object +to which this keyword's schema applies is empty. + +This annotation affects the behavior of `unevaluatedItems` in the Unevaluated +vocabulary. + +The subschema MUST be applied to every array element or object property value +even after the first match has been found, in order to collect annotations for +use by other keywords. This is to ensure that all possible annotations are +collected. + +## A Vocabulary for Unevaluated Locations + +The purpose of these keywords is to enable schema authors to apply subschemas to +array items or object properties that have not been successfully evaluated +against any dynamic-scope subschema of any adjacent keywords. + +These instance items or properties may have been unsuccessfully evaluated +against one or more adjacent keyword subschemas, such as when an assertion in a +branch of an `anyOf` fails. Such failed evaluations are not considered to +contribute to whether or not the item or property has been evaluated. Only +successful evaluations are considered. + +If an item in an array or an object property is "successfully evaluated", it is +logically considered to be valid in terms of the representation of the object or +array that's expected. For example if a subschema represents a car, which +requires between 2-4 wheels, and the value of "wheels" is 6, the instance object +is not "evaluated" to be a car, and the "wheels" property is considered +"unevaluated (successfully as a known thing)", and does not retain any +annotations. + +Recall that adjacent keywords are keywords within the same schema object, and +that the dynamic-scope subschemas include reference targets as well as lexical +subschemas. + +The behavior of these keywords depend on the annotation results of adjacent +keywords that apply to the instance location being validated. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Unevaluated Applicator +vocabulary, is: `https://json-schema.org/draft/next/vocab/unevaluated`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/unevaluated`. + +### Keyword Independence + +Schema keywords typically operate independently, without affecting each other's +outcomes. However, the keywords in this vocabulary are notable exceptions: + +- `unevaluatedItems`, whose behavior is defined in terms of annotations from + `prefixItems`, `items`, `contains`, and itself +- `unevaluatedProperties`, whose behavior is defined in terms of annotations + from `properties`, `patternProperties`, `additionalProperties`, `contains`, + and itself + +### `unevaluatedItems` {#unevaluateditems} + +The value of `unevaluatedItems` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the annotation results of adjacent +keywords that apply to the instance location being validated. Specifically, the +annotations from `prefixItems`, `items`, and `contains`, which can come from +those keywords when they are adjacent to the `unevaluatedItems` keyword. Those +three annotations, as well as `unevaluatedItems`, can also result from any and +all adjacent [in-place applicator](#in-place) keywords. This includes but is not +limited to the in-place applicators defined in this document. + +If no relevant annotations are present, the `unevaluatedItems` subschema MUST be +applied to all locations in the array. If a boolean true value is present from +any of the relevant annotations, `unevaluatedItems` MUST be ignored. Otherwise, +the subschema MUST be applied to any index greater than the largest annotation +value for `prefixItems`, which does not appear in any annotation value for +`contains`. + +This means that `prefixItems`, `items`, `contains`, and all in-place applicators +MUST be evaluated before this keyword can be evaluated. Authors of extension +keywords MUST NOT define an in-place applicator that would need to be evaluated +after this keyword. + +If the `unevaluatedItems` subschema is applied to any positions within the +instance array, it produces an annotation result of boolean true, analogous to +the behavior of `items`. This annotation affects the behavior of +`unevaluatedItems` in parent schemas. + +Omitting this keyword has the same assertion behavior as an empty schema. + +### `unevaluatedProperties` {#unevaluatedproperties} + +The value of `unevaluatedProperties` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the annotation results of adjacent +keywords that apply to the instance location being validated. Specifically, the +annotations from `properties`, `patternProperties`, `contains`, and +`additionalProperties`, which can come from those keywords when they are +adjacent to the `unevaluatedProperties` keyword. Those four annotations, as well +as `unevaluatedProperties`, can also result from any and all adjacent [in-place +applicator](#in-place) keywords. This includes but is not limited to the +in-place applicators defined in this document. + +Validation with `unevaluatedProperties` applies only to the child values of +instance names that do not appear in the `properties`, `patternProperties`, +`additionalProperties`, `contains`, or `unevaluatedProperties` annotation +results that apply to the instance location being validated. + +For all such properties, validation succeeds if the child instance validates +against the `unevaluatedProperties` schema. + +This means that `properties`, `patternProperties`, `additionalProperties`, +`contains` and all in-place applicators MUST be evaluated before this keyword +can be evaluated. Authors of extension keywords MUST NOT define an in-place +applicator that would need to be evaluated after this keyword. + +The annotation result of this keyword is the set of instance property names +validated by this keyword's subschema. This annotation affects the behavior of +`unevaluatedProperties` in parent schemas. + +Omitting this keyword has the same assertion behavior as an empty schema. + +## Output Formatting {#output} + +JSON Schema is defined to be platform-independent. As such, to increase +compatibility across platforms, implementations SHOULD conform to a standard +validation output format. This section describes the minimum requirements that +consumers will need to properly interpret validation results. + +### Format + +JSON Schema output is defined using the JSON Schema data instance model as +described in section 4.2.1. Implementations MAY deviate from this as supported +by their specific languages and platforms, however it is RECOMMENDED that the +output be convertible to the JSON format defined herein via serialization or +other means. + +### Output Formats + +This specification defines three output formats. See the "Output Structure" +section for the requirements of each format. + +- *Flag*: A boolean which simply indicates the overall validation result with no + further details. +- *List*: Provides validation information in a flat list structure. + +Hierarchical: Provides validation information in a hierarchical structure that +follows the evaluation paths generated while processing the schema. + +An implementation MUST provide the "flag" format and SHOULD provide at least one +of the "list" or "hierarchical" formats. Implementations SHOULD specify in their +documentation which formats they support. + +### Minimum Information + +Beyond the simplistic "flag" output, additional information is useful to aid in +debugging a schema or instance. Each sub-result SHOULD contain the information +contained within this section at a minimum. + +A single object that contains all of these components is considered an output +unit. + +Implementations MAY elect to provide additional information. + +#### Evaluation path + +The evaluation path to the schema object that produced the output unit. The +value MUST be expressed as a JSON Pointer, and it MUST include any by-reference +applicators such as `$ref` or `$dynamicRef`.[^13] + +[^13]: The schema may not actually have a value at the location indicated by +this pointer. It is provided as an indication of the traversal path only. + +``` +/properties/width/$ref/allOf/1 +``` + +Note that this pointer may not be resolvable by the normal JSON Pointer process +due to the inclusion of these by-reference applicator keywords. + +The JSON key for this information is "evaluationPath". + +#### Schema Location + +The absolute, dereferenced location of the schema object that produced the +output unit. The value MUST be expressed using the canonical IRI of the relevant +schema resource plus a JSON Pointer fragment that indicates the schema object +that produced the output. It MUST NOT include by-reference applicators such as +`$ref` or `$dynamicRef`.[^14] + +[^14]: Note that "absolute" here is in the sense of "absolute filesystem path" +(meaning the complete location) rather than the "absolute-IRI" terminology from +RFC 3987 (meaning with scheme and without fragment). Schema locations will have +a fragment in order to identify the specific schema object. + +``` +https://example.com/schemas/common#/$defs/allOf/1 +``` + +The JSON key for this information is "schemaLocation". + +#### Instance Location + +The location of the JSON value within the instance being validated. The value +MUST be expressed as a JSON Pointer. + +The JSON key for this information is "instanceLocation". + +#### Errors + +Any errors produced by the validation. This property MUST NOT be included if the +validation was successful. The value for this property MUST be an object where +the keys are the names of keywords and the values are the error message produced +by the associated keyword. + +If the subschema itself is producing the error, that error MUST be listed with +an empty string key.[^15] + +[^15]: Although there may be other cases where a subschema can produce an error, +the most common case is the `false` schema. In cases like these, there is no +keyword that produces the error, so there is nothing to use as a key. Thus the +empty string is used instead. + +The specific wording for the message is not defined by this specification. +Implementations will need to provide this. + +The JSON key for this information is "errors". + +#### Annotations + +Any annotations produced by the evaluation. This property MUST NOT be included +if the validation result of the containing subschema was unsuccessful. + +The value for this property MUST be an object where the keys are the names of +keywords and the values are the annotations produced by the associated keyword. + +Each keyword defines its own annotation data type (e.g. `properties` produces a +list of keywords, whereas `title` produces a string). + +The JSON key for this information is "annotations". + +#### Dropped Annotations + +Any annotations produced and subsequently dropped by the evaluation due to an +unsuccessful validation result of the containing subschema. This property MAY be +included if the validation result of the containing subschema was unsuccessful. +It MUST NOT be included if the local validation result of the containing +subschema was successful. + +Implementations that wish to provide these annotations MUST NOT provide them as +their default behavior. These annotations MUST only be included by explicitly +configuring the implementation to do so. + +The value for this property MUST be an object where the keys are the names of +keywords and the values are the annotations produced by the associated keyword. + +Each keyword defines its own annotation data type (e.g. `properties` produces a +list of keywords, whereas `title` produces a string). + +The JSON key for this information is "droppedAnnotations". + +#### Results from Subschemas + +Evaluation results generated by applying a subschema to the instance or a child +of the instance. Keywords which have multiple subschemas (e.g. `anyOf`) will +generally generate an output unit for each subschema. In order to accommodate +potentially multiple results, the value of this property MUST be an array of +output units, even if only a single output unit is produced. + +For "list", this property will appear only at the root output unit and will hold +all output units in a flat list. + +For "hierarchical", this property will contain results in a tree structure where +each output unit may itself have further nested results. + +The sequence of output units within this list is not specified and MAY be +determined by the implementation. Sets of output units are considered equivalent +if they contain the same units, in any order. + +The JSON key for these additional results is "details". + +### Output Structure + +The output MUST be an object containing a boolean property named "valid". When +additional information about the result is required, the output MUST also +contain "details" as described below. + +valid: a boolean value indicating the overall validation success or failure + +details: the collection of results produced by subschemas + +For these examples, the following schema and instances will be used. + +```jsonschema +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/schemas/example", + "type": "object", + "title": "root", + "properties": { + "foo": { + "allOf": [ + { "required": [ "unspecified-prop" ] }, + { + "type": "object", + "title": "foo-title", + "properties": { + "foo-prop": { + "const": 1, + "title": "foo-prop-title" + } + }, + "additionalProperties": { "type": "boolean" } + } + ] + }, + "bar": { + "$ref": "#/$defs/bar" + } + }, + "$defs": { + "bar": { + "type": "object", + "title": "bar-title", + "properties": { + "bar-prop": { + "type": "integer", + "minimum": 10, + "title": "bar-prop-title" + } + } + } + } +} +``` + + +```json "Failing instance" +{ + "foo": {"foo-prop": "not 1", "other-prop": false}, + "bar": {"bar-prop": 2} +} +``` + +```json "Passing instance" +{ + "foo": { + "foo-prop": 1, + "unspecified-prop": true + }, + "bar": {"bar-prop": 20} +} +``` + +The failing instance will produce the following errors: + +- The value at `/foo` evaluated at `/properties/foo/allOf/0` by following the + path `/properties/foo/allOf/0` by the `required` keyword is missing the + property `unspecified-prop`. +- The value at `/foo/foo-prop` evaluated at + `/properties/foo/allOf/1/properties/foo-prop` by following the path + `/properties/foo/allOf/1/properties/foo-prop` by the `const` keyword is not + the constant value 1. +- The value at `/bar/bar-prop` evaluated at `/$defs/bar/properties/bar-prop` by + following the path `/properties/bar/$ref/properties/bar-prop` by the `type` + keyword is not a number.[^16][^17] + +[^16]: `minimum` doesn't produce an error because it only operates on instances +that are numbers. + +[^17]: Note that the error message wording as depicted in the examples below is +not a requirement of this specification. Implementations SHOULD craft error +messages tailored for their audience or provide a templating mechanism that +allows their users to craft their own messages. + +The passing instance will produce the following annotations: + +- The keyword `title` evaluated at `` by following the path `` will produce + `"root"`. +- The keyword `properties` evaluated at `` by following the path `` will produce + `["foo", "bar"]`. +- The keyword `title` evaluated at `/properties/foo` by following the path + `/properties/foo` will produce `"foo-title"`. +- The keyword `properties` evaluated at `/properties/foo/allOf/1` by following + the path `/properties/foo/allOf/1` will produce `["foo-prop"]`. +- The keyword `additionalProperties` evaluated at `/properties/foo/allOf/1` by + following the path `/properties/foo/allOf/1` will produce + `["unspecified-prop"]`. +- The keyword `title` evaluated at `/properties/foo/allOf/1/properties/foo-prop` + by following the path `/properties/foo/allOf/1/properties/foo-prop` will + produce `"foo-prop-title"`. +- The keyword `title` evaluated at `/$defs/bar` by following the path + `/properties/bar/$ref` will produce `"bar-title"`. +- The keyword `properties` evaluated at `/$defs/bar` by following the path + `/properties/var/$ref` will produce `["bar-prop"]`. +- The keyword `title` evaluated at `/$defs/bar/properties/bar-prop` by following + the path `/properties/bar/$ref/properties/bar-prop` will produce + `"bar-prop-title"`. + +#### Flag + +In the simplest case, merely the boolean result for the "valid" valid property +needs to be fulfilled. For this format, all other information is explicitly +omitted. + +```json +{ + "valid": false +} +``` + +Because no errors or annotations are returned with this format, it is +RECOMMENDED that implementations use short-circuiting logic to return failure or +success as soon as the outcome can be determined. For example, if an `anyOf` +keyword contains five subschemas, and the second one passes, there is no need to +check the other three. The logic can simply return with success. + +#### List + +The "List" structure is a flat list of output units contained within a root +output unit. + +The root output unit contains "valid" for the overall result and "details" for +the list of specific results. All other information is explicitly omitted from +the root output unit. If the root schema produces errors or annotations, then +the output node for the root MUST be present within the root output unit's +"details" list with those errors or annotations. + +Output units which do not contain errors or annotations SHOULD be excluded from +this format, however implementations MAY choose to include them for +completeness. + +```json "Failing results" +{ + "valid": false, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "required": "Required properties [\"unspecified-prop\"] were not present" + } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected \"1\"" + } + }, + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "minimum": "2 is less than or equal to 10" + } + } + ] +} +``` + +```json "Passing results" +{ + "valid": true, + "details": [ + { + "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "annotations": { + "title": "root", + "properties": [ + "foo", + "bar" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "annotations": { + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ + "bar-prop" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "annotations": { + "title": "bar-prop-title" + } + } + ] +} +``` + +#### Hierarchical + +The "Hierarchical" structure is a tree structure that follows the evaluation +path during the validation process. Typically, it will resemble the schema as if +all referenced schemas were inlined in place of their associated by-reference +keywords. + +All output units are included in this format. + +The location properties of the root output unit MAY be omitted. + +```json "Failing results (errors)" +{ + "valid": false, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "required": "Required properties [\"unspecified-prop\"] were not present" + } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "droppedAnnotations": { + "properties": [ "foo-prop" ], + "title": "foo-title" + }, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected \"1\"" + }, + "droppedAnnotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", + "instanceLocation": "/foo/other-prop" + } + ] + } + ] + }, + { + "valid": false, + "evaluationPath": "/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "droppedAnnotations": { + "properties": [ "bar-prop" ], + "title": "bar-title" + }, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "minimum": "2 is less than or equal to 10" + }, + "droppedAnnotations": { + "title": "bar-prop-title" + } + } + ] + } + ] + } + ] +} +``` + +```json "Passing results (annotations)" +{ + "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "annotations": { + "title": "root", + "properties": [ + "foo", + "bar" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo" + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "annotations": { + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", + "instanceLocation": "/foo/unspecified-prop" + } + ] + } + ] + }, + { + "valid": true, + "evaluationPath": "/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "details": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ + "bar-prop" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "annotations": { + "title": "bar-prop-title" + } + } + ] + } + ] + } + ] +} +``` + +#### Output validation schemas + +For convenience, JSON Schema has been provided to validate output generated by +implementations. Its IRI is: . + +## Security Considerations {#security} + +Both schemas and instances are JSON values. As such, all security considerations +defined in [RFC 8259](#rfc8259) apply. + +Instances and schemas are both frequently written by untrusted third parties, to +be deployed on public Internet servers. Implementations should take care that +the parsing and evaluating against schemas does not consume excessive system +resources. Implementations MUST NOT fall into an infinite loop. + +A malicious party could cause an implementation to repeatedly collect a copy of +a very large value as an annotation. Implementations SHOULD guard against +excessive consumption of system resources in such a scenario. + +Servers MUST ensure that malicious parties cannot change the functionality of +existing schemas by uploading a schema with a pre-existing or very similar +`$id`. + +Individual JSON Schema vocabularies are liable to also have their own security +considerations. Consult the respective specifications for more information. + +Schema authors should take care with `$comment` contents, as a malicious +implementation can display them to end-users in violation of a spec, or fail to +strip them if such behavior is expected. + +A malicious schema author could place executable code or other dangerous +material within a `$comment`. Implementations MUST NOT parse or otherwise take +action based on `$comment` contents. + +## IANA Considerations + +### `application/schema+json` + +The proposed MIME media type for JSON Schema is defined as follows: + +Type name:: application + +Subtype name:: schema+json + +Required parameters:: N/A + +Encoding considerations:: Encoding considerations are identical to those +specified for the `application/json` media type. See [JSON](#rfc8259). + +Security considerations:: See {{security}} above. + +Interoperability considerations:: See Sections [6.2](#language), +[6.3](#integers), and [6.4](#regex) above. + +Fragment identifier considerations:: See {{fragments}} + +### `application/schema-instance+json` + +The proposed MIME media type for JSON Schema Instances that require a JSON +Schema-specific media type is defined as follows: + +Type name:: application + +Subtype name:: schema-instance+json + +Required parameters:: N/A + +Encoding considerations:: Encoding considerations are identical to those +specified for the `application/json` media type. See [JSON](#rfc8259). + +Security considerations:: See {{security}} above. + +Interoperability considerations:: See Sections [6.2](#language), +[6.3](#integers), and [6.4](#regex) above. + +Fragment identifier considerations:: See {{fragments}} + +## References + +### Normative References + +#### [RFC2119] {#rfc2119} + +Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, +RFC 2119, DOI 10.17487/RFC2119, March 1997, +<>. + +#### [RFC3986] {#rfc3986} + +Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier +(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, +<>. + +#### [RFC3987] {#rfc3987} + +Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC +3987, DOI 10.17487/RFC3987, January 2005, +<>. + +#### [RFC6839] {#rfc6839} + +Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", +RFC 6839, DOI 10.17487/RFC6839, January 2013, +<>. + +#### [RFC6901] {#rfc6901} + +Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation +(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, +<>. + +#### [RFC8259] {#rfc8259} + +Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", +STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, +<>. + +#### [W3C.REC-ldp-20150226] {#w3crec-ldp-20150226} + +Malhotra, A., Ed., Arwe, J., Ed., and S. Speicher, Ed., "Linked Data Platform +1.0", W3C REC REC-ldp-20150226, W3C REC-ldp-20150226, 26 February 2015, +<>. + +#### [ecma262] {#ecma262} + +"ECMA-262, 11th edition specification", June 2020, +<>. + +### Informative References + +#### [RFC6596] {#rfc6596} + +Ohye, M. and J. Kupke, "The Canonical Link Relation", RFC 6596, DOI +10.17487/RFC6596, April 2012, <>. + +#### [RFC7049] {#rfc7049} + +Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC +7049, DOI 10.17487/RFC7049, October 2013, +<>. + +#### [RFC7231] {#rfc7231} + +Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): +Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, +<>. + +#### [RFC8288] {#rfc8288} + +Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, +<>. + +#### [W3C.WD-fragid-best-practices-20121025] +{#w3cwd-fragid-best-practices-20121025} + +Tennison, J., Ed., "Best Practices for Fragment Identifiers and Media Type +Definitions", W3C WD WD-fragid-best-practices-20121025, W3C +WD-fragid-best-practices-20121025, 25 October 2012, +<>. + +#### [W3C.REC-xptr-framework-20030325] {#w3crec-xptr-framework-20030325} + +Maler, E., Ed., Marsh, J., Ed., Walsh, N., Ed., and P. Grosso, Ed., "XPointer +Framework", W3C REC REC-xptr-framework-20030325, W3C +REC-xptr-framework-20030325, 25 March 2003, +<>. + +#### [json-schema-validation] {#json-schema-validation} + +Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary +for Structural Validation of JSON", Work in Progress, Internet-Draft, +draft-bhutton-json-schema-validation-01, June 2022, +<>. + +#### [json-hyper-schema] {#json-hyper-schema} + +Andrews, H. and A. Wright, "JSON Hyper-Schema: A Vocabulary for Hypermedia +Annotation of JSON", Work in Progress, Internet-Draft, +draft-handrews-json-schema-hyperschema-02, November 2017, +<>. + +#### [xml-names] {#xml-names} + +Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., +"Namespaces in XML 1.1 (Second Edition)", August 2006, +<>. + +## [Appendix] Schema identification examples {#idexamples} + +Consider the following schema, which shows `$id` being used to identify both the +root schema and various subschemas, and `$anchor` being used to define plain +name fragment identifiers. + +```jsonschema +{ + "$id": "https://example.com/root.json", + "$defs": { + "A": { "$anchor": "foo" }, + "B": { + "$id": "other.json", + "$defs": { + "X": { "$anchor": "bar" }, + "Y": { + "$id": "t/inner.json", + "$anchor": "bar" + } + } + }, + "C": { + "$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f" + } + } +} +``` + +The schemas at the following IRI-encoded [JSON Pointers](#rfc6901) (relative to +the root schema) have the following base IRIs, and are identifiable by any +listed IRI in accordance with {{fragments}} and {{embedded}} above. + +`#` (document root): canonical (and base) IRI: `https://example.com/root.json` +- canonical resource IRI plus pointer fragment: `https://example.com/root.json#` + +`#/$defs/A`: base IRI: `https://example.com/root.json` +- canonical resource IRI plus plain fragment: + `https://example.com/root.json#foo` +- canonical resource IRI plus pointer fragment: + `https://example.com/root.json#/$defs/A` + +`#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` +- canonical resource IRI plus pointer fragment: + `https://example.com/other.json#` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B` + +`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` +- canonical resource IRI plus plain fragment: + `https://example.com/other.json#bar` +- canonical resource IRI plus pointer fragment: + `https://example.com/other.json#/$defs/X` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/X` + +`#/$defs/B/$defs/Y`: canonical (and base) IRI: +`https://example.com/t/inner.json` +- canonical IRI plus plain fragment: `https://example.com/t/inner.json#bar` +- canonical IRI plus pointer fragment: `https://example.com/t/inner.json#` +- base IRI of enclosing (other.json) resource plus fragment: + `https://example.com/other.json#/$defs/Y` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/Y` + +`#/$defs/C`: canonical (and base) IRI: +`urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` +- canonical IRI plus pointer fragment: + `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/C` + +Note: The fragment part of the IRI does not make it canonical or non-canonical, +rather, the base IRI used (as part of the full IRI with any fragment) is what +determines the canonical nature of the resulting full IRI.[^18] + +[^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, +and direct you to read the CREF located in the [JSON Pointer fragments and +embedded schema resources](#embedded) section for further comments. + +## [Appendix] Manipulating schema documents and references + +Various tools have been created to rearrange schema documents based on how and +where references (`$ref`) appear. This appendix discusses which use cases and +actions are compliant with this specification. + +### Bundling schema resources into a single document + +A set of schema resources intended for use together can be organized with each +in its own schema document, all in the same schema document, or any granularity +of document grouping in between. + +Numerous tools exist to perform various sorts of reference removal. A common +case of this is producing a single file where all references can be resolved +within that file. This is typically done to simplify distribution, or to +simplify coding so that various invocations of JSON Schema libraries do not have +to keep track of and load a large number of resources. + +This transformation can be safely and reversibly done as long as all static +references (e.g. `$ref`) use IRI-references that resolve to IRIs using the +canonical resource IRI as the base, and all schema resources have an +absolute-IRI as the `$id` in their root schema. + +With these conditions met, each external resource can be copied under `$defs`, +without breaking any references among the resources' schema objects, and without +changing any aspect of validation or annotation results. The names of the +schemas under `$defs` do not affect behavior, assuming they are each unique, as +they do not appear in the canonical IRIs for the embedded resources. + +### Reference removal is not always safe + +Attempting to remove all references and produce a single schema document does +not, in all cases, produce a schema with identical behavior to the original +form. + +Since `$ref` is now treated like any other keyword, with other keywords allowed +in the same schema objects, fully supporting non-recursive `$ref` removal in all +cases can require relatively complex schema manipulations. It is beyond the +scope of this specification to determine or provide a set of safe `$ref` removal +transformations, as they depend not only on the schema structure but also on the +intended usage. + +## [Appendix] Example of recursive schema extension {#recursive-example} + +Consider the following two schemas describing a simple recursive tree structure, +where each node in the tree can have a "data" field of any type. The first +schema allows and ignores other instance properties. The second is more strict +and only allows the "data" and "children" properties. An example instance with +"data" misspelled as "daat" is also shown. + +```jsonschema "Tree schema, extensible" +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/tree", + "$dynamicAnchor": "node", + + "type": "object", + "properties": { + "data": true, + "children": { + "type": "array", + "items": { + "$dynamicRef": "#node" + } + } + } +} +``` + +```jsonschema "Strict-tree schema, guards against misspelled properties" +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/strict-tree", + "$dynamicAnchor": "node", + + "$ref": "tree", + "unevaluatedProperties": false +} +``` + +```jsonschema "Instance with misspelled field" +{ + "children": [ { "daat": 1 } ] +} +``` + +When we load these two schemas, we will notice the `$dynamicAnchor` named "node" +(note the lack of "#" as this is just the name) present in each, resulting in +the following full schema IRIs: + +- `https://example.com/tree#node` +- `https://example.com/strict-tree#node` + +In addition, JSON Schema implementations keep track of the fact that these +fragments were created with `$dynamicAnchor`. + +If we apply the "strict-tree" schema to the instance, we will follow the `$ref` +to the "tree" schema, examine its "children" subschema, and find the +`$dynamicRef`: to "#node" (note the `#` for IRI fragment syntax) in its `items` +subschema. That reference resolves to `https://example.com/tree#node`, which is +a IRI with a fragment created by `$dynamicAnchor`. Therefore we must examine the +dynamic scope before following the reference. + +At this point, the evaluation path is +`#/$ref/properties/children/items/$dynamicRef`, with a dynamic scope containing +(from the outermost scope to the innermost): + +1. `https://example.com/strict-tree#` +1. `https://example.com/tree#` +1. `https://example.com/tree#/properties/children` +1. `https://example.com/tree#/properties/children/items` + +Since we are looking for a plain name fragment, which can be defined anywhere +within a schema resource, the JSON Pointer fragments are irrelevant to this +check. That means that we can remove those fragments and eliminate consecutive +duplicates, producing: + +1. `https://example.com/strict-tree` +1. `https://example.com/tree` + +In this case, the outermost resource also has a "node" fragment defined by +`$dynamicAnchor`. Therefore instead of resolving the `$dynamicRef` to +`https://example.com/tree#node`, we resolve it to +`https://example.com/strict-tree#node`. + +This way, the recursion in the "tree" schema recurses to the root of +"strict-tree", instead of only applying "strict-tree" to the instance root, but +applying "tree" to instance children. + +This example shows both `$dynamicAnchor`s in the same place in each schema, +specifically the resource root schema. Since plain-name fragments are +independent of the JSON structure, this would work just as well if one or both +of the node schema objects were moved under `$defs`. It is the matching +`$dynamicAnchor` values which tell us how to resolve the dynamic reference, not +any sort of correlation in JSON structure. + +## [Appendix] Working with vocabularies + +### Best practices for vocabulary and meta-schema authors {#vocab-practices} + +Vocabulary authors should take care to avoid keyword name collisions if the +vocabulary is intended for broad use, and potentially combined with other +vocabularies. JSON Schema does not provide any formal namespacing system, but +also does not constrain keyword names, allowing for any number of namespacing +approaches. + +Vocabularies may build on each other, such as by defining the behavior of their +keywords with respect to the behavior of keywords from another vocabulary, or by +using a keyword from another vocabulary with a restricted or expanded set of +acceptable values. Not all such vocabulary re-use will result in a new +vocabulary that is compatible with the vocabulary on which it is built. +Vocabulary authors should clearly document what level of compatibility, if any, +is expected. + +Meta-schema authors should not use `$vocabulary` to combine multiple +vocabularies that define conflicting syntax or semantics for the same keyword. +As semantic conflicts are not generally detectable through schema validation, +implementations are not expected to detect such conflicts. If conflicting +vocabularies are declared, the resulting behavior is undefined. + +Vocabulary authors SHOULD provide a meta-schema that validates the expected +usage of the vocabulary's keywords on their own. Such meta-schemas SHOULD not +forbid additional keywords, and MUST not forbid any keywords from the Core +vocabulary. + +It is recommended that meta-schema authors reference each vocabulary's +meta-schema using the [`allOf`](#allof) keyword, although other mechanisms for +constructing the meta-schema may be appropriate for certain use cases. + +The recursive nature of meta-schemas makes the `$dynamicAnchor` and +`$dynamicRef` keywords particularly useful for extending existing meta-schemas, +as can be seen in the JSON Hyper-Schema meta-schema which extends the Validation +meta-schema. + +Meta-schemas may impose additional constraints, including describing keywords +not present in any vocabulary, beyond what the meta-schemas associated with the +declared vocabularies describe. This allows for restricting usage to a subset of +a vocabulary, and for validating locally defined keywords not intended for +re-use. + +However, meta-schemas should not contradict any vocabularies that they declare, +such as by requiring a different JSON type than the vocabulary expects. The +resulting behavior is undefined. + +Meta-schemas intended for local use, with no need to test for vocabulary support +in arbitrary implementations, can safely omit `$vocabulary` entirely. + +### Example meta-schema with vocabulary declarations {#example-meta-schema} + +This meta-schema explicitly declares both the Core and Applicator vocabularies, +together with an extension vocabulary, and combines their meta-schemas with an +`allOf`. The extension vocabulary's meta-schema, which describes only the +keywords in that vocabulary, is shown after the main example meta-schema. + +The main example meta-schema also restricts the usage of the Unevaluated +vocabulary by forbidding the keywords prefixed with "unevaluated", which are +particularly complex to implement. This does not change the semantics or set of +keywords defined by the other vocabularies. It just ensures that schemas using +this meta-schema that attempt to use the keywords prefixed with "unevaluated" +will fail validation against this meta-schema. + +Finally, this meta-schema describes the syntax of a keyword, "localKeyword", +that is not part of any vocabulary. Presumably, the implementors and users of +this meta-schema will understand the semantics of "localKeyword". JSON Schema +does not define any mechanism for expressing keyword semantics outside of +vocabularies, making them unsuitable for use except in a specific environment in +which they are understood. + +This meta-schema combines several vocabularies for general use. + +```jsonschema +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/meta/general-use-example", + "$dynamicAnchor": "meta", + "$vocabulary": { + "https://json-schema.org/draft/next/vocab/core": true, + "https://json-schema.org/draft/next/vocab/applicator": true, + "https://json-schema.org/draft/next/vocab/validation": true, + "https://example.com/vocab/example-vocab": true + }, + "allOf": [ + {"$ref": "https://json-schema.org/draft/next/meta/core"}, + {"$ref": "https://json-schema.org/draft/next/meta/applicator"}, + {"$ref": "https://json-schema.org/draft/next/meta/validation"}, + {"$ref": "https://example.com/meta/example-vocab", + ], + "patternProperties": { + "^unevaluated": false + }, + "properties": { + "localKeyword": { + "$comment": "Not in vocabulary, but validated if used", + "type": "string" + } + } +} +``` + +This meta-schema describes only a single extension vocabulary. + +```jsonschema +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/meta/example-vocab", + "$dynamicAnchor": "meta", + "$vocabulary": { + "https://example.com/vocab/example-vocab": true, + }, + "type": ["object", "boolean"], + "properties": { + "minDate": { + "type": "string", + "pattern": "\\d\\d\\d\\d-\\d\\d-\\d\\d", + "format": "date", + } + } +} +``` + +As shown above, even though each of the single-vocabulary meta-schemas +referenced in the general-use meta-schema's `allOf` declares its corresponding +vocabulary, this new meta-schema must re-declare them. + +The standard meta-schemas that combine all vocabularies defined by the Core and +Validation specification, and that combine all vocabularies defined by those +specifications as well as the Hyper-Schema specification, demonstrate additional +complex combinations. These IRIs for these meta-schemas may be found in the +Validation and Hyper-Schema specifications, respectively. + +While the general-use meta-schema can validate the syntax of `minDate`, it is +the vocabulary that defines the logic behind the semantic meaning of `minDate`. +Without an understanding of the semantics (in this example, that the instance +value must be a date equal to or after the date provided as the keyword's value +in the schema), an implementation can only validate the syntactic usage. In this +case, that means validating that it is a date-formatted string (using `pattern` +to ensure that it is validated even when `format` functions purely as an +annotation, as explained in the [Validation +specification](#json-schema-validation). + +## [Appendix] References and generative use cases + +While the presence of references is expected to be transparent to validation +results, generative use cases such as code generators and UI renderers often +consider references to be semantically significant. + +To make such use case-specific semantics explicit, the best practice is to +create an annotation keyword for use in the same schema object alongside of a +reference keyword such as `$ref`. + +For example, here is a hypothetical keyword for determining whether a code +generator should consider the reference target to be a distinct class, and how +those classes are related. Note that this example is solely for illustrative +purposes, and is not intended to propose a functional code generation keyword. + +```jsonschema +{ + "allOf": [ + { + "classRelation": "is-a", + "$ref": "classes/base.json" + }, + { + "$ref": "fields/common.json" + } + ], + "properties": { + "foo": { + "classRelation": "has-a", + "$ref": "classes/foo.json" + }, + "date": { + "$ref": "types/dateStruct.json", + } + } +} +``` + +Here, this schema represents some sort of object-oriented class. The first +reference in the `allOf` is noted as the base class. The second is not assigned +a class relationship, meaning that the code generator should combine the +target's definition with this one as if no reference were involved. + +Looking at the properties, "foo" is flagged as object composition, while the +"date" property is not. It is simply a field with sub-fields, rather than an +instance of a distinct class. + +This style of usage requires the annotation to be in the same object as the +reference, which must be recognizable as a reference. + +## [Appendix] Acknowledgments + +Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry +Andrews for their work on the initial drafts of JSON Schema. + +Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Evgeny Poberezkin, Brad +Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil +Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches +to the document. + +## [Appendix] Change Log[^19] + +[^19]: This section to be removed before leaving Internet-Draft status. + +### draft-bhutton-json-schema-next +- `contains` now applies to objects as well as arrays +- Use IRIs instead of URIs +- Remove bookending requirement for `$dynamicRef` +- Add `propertyDependencies` keyword + +### draft-bhutton-json-schema-01 +- Improve and clarify the `type`, `contains`, `unevaluatedProperties`, and + `unevaluatedItems` keyword explanations +- Clarify various aspects of "canonical URIs" +- Comment on ambiguity around annotations and `additionalProperties` +- Clarify Vocabularies need not be formally defined +- Remove references to remaining media-type parameters +- Fix multiple examples + +### draft-bhutton-json-schema-00 +- `$schema` MAY change for embedded resources +- Array-value `items` functionality is now `prefixItems` +- `items` subsumes the old function of `additionalItems` +- `contains` annotation behavior, and `contains` and `unevaluatedItems` + interactions now specified +- Rename $recursive* to $dynamic*, with behavior modification +- $dynamicAnchor defines a fragment like $anchor +- $dynamic* (previously $recursive) no longer use runtime base URI determination +- Define Compound Schema Documents (bundle) and processing +- Reference ECMA-262, 11th edition for regular expression support +- Regular expression should support unicode +- Remove media type parameters +- Specify Unknown keywords are collected as annotations +- Moved `unevaluatedItems` and `unevaluatedProperties` from core into their own + vocabulary + +### draft-handrews-json-schema-02 +- Update to RFC 8259 for JSON specification +- Moved `definitions` from the Validation specification here as `$defs` +- Moved applicator keywords from the Validation specification as their own + vocabulary +- Moved the schema form of `dependencies` from the Validation specification as + `dependentSchemas` +- Formalized annotation collection +- Specified recommended output formats +- Defined keyword interactions in terms of annotation and assertion results +- Added `unevaluatedProperties` and `unevaluatedItems` +- Define `$ref` behavior in terms of the assertion, applicator, and annotation + model +- Allow keywords adjacent to `$ref` +- Note undefined behavior for `$ref` targets involving unknown keywords +- Add recursive referencing, primarily for meta-schema extension +- Add the concept of formal vocabularies, and how they can be recognized through + meta-schemas +- Additional guidance on initial base URIs beyond network retrieval +- Allow "schema" media type parameter for `application/schema+json` +- Better explanation of media type parameters and the HTTP Accept header +- Use `$id` to establish canonical and base absolute-URIs only, no fragments +- Replace plain-name-fragment-only form of `$id` with `$anchor` +- Clarified that the behavior of JSON Pointers across `$id` boundary is + unreliable + +### draft-handrews-json-schema-01 +- This draft is purely a clarification with no functional changes +- Emphasized annotations as a primary usage of JSON Schema +- Clarified $id by use cases +- Exhaustive schema identification examples +- Replaced "external referencing" with how and when an implementation might know + of a schema from another document +- Replaced "internal referencing" with how an implementation should recognized + schema identifiers during parsing +- Dereferencing the former "internal" or "external" references is always the + same process +- Minor formatting improvements + +### draft-handrews-json-schema-00 +- Make the concept of a schema keyword vocabulary more clear +- Note that the concept of "integer" is from a vocabulary, not the data model +- Classify keywords as assertions or annotations and describe their general + behavior +- Explain the boolean schemas in terms of generalized assertions +- Reserve `$comment` for non-user-visible notes about the schema +- Wording improvements around `$id` and fragments +- Note the challenges of extending meta-schemas with recursive references +- Add `application/schema-instance+json` media type +- Recommend a "schema" link relation / parameter instead of "profile" + +### draft-wright-json-schema-01 +- Updated intro +- Allowed for any schema to be a boolean +- `$schema` SHOULD NOT appear in subschemas, although that may change +- Changed `id` to `$id`; all core keywords prefixed with "$" +- Clarify and formalize fragments for `application/schema+json` +- Note applicability to formats such as CBOR that can be represented in the JSON + data model + +### draft-wright-json-schema-00 +- Updated references to JSON +- Updated references to HTTP +- Updated references to JSON Pointer +- Behavior for `id` is now specified in terms of RFC3986 +- Aligned vocabulary usage for URIs with RFC3986 +- Removed reference to draft-pbryan-zyp-json-ref-03 +- Limited use of `$ref` to wherever a schema is expected +- Added definition of the "JSON Schema data model" +- Added additional security considerations +- Defined use of subschema identifiers for `id` +- Rewrote section on usage with HTTP +- Rewrote section on usage with rel="describedBy" and rel="profile" +- Fixed numerous invalid examples + +### draft-zyp-json-schema-04 +- Salvaged from draft v3. +- Split validation keywords into separate document. +- Split hypermedia keywords into separate document. +- Initial post-split draft. +- Mandate the use of JSON Reference, JSON Pointer. +- Define the role of `id`. Define URI resolution scope. +- Add interoperability considerations. + +### draft-zyp-json-schema-00 +- Initial draft. + +## Authors' Addresses +| Author | Company | Email | URI | +|--------------------------|---------|-------------------------|----------------------------------| +| Austin Wright (*editor*) | | | | +| Ben Hutton (*editor*) | Postman | | | +| Greg Dennis | | | | diff --git a/jsonschema-core.xml b/jsonschema-core.xml deleted file mode 100644 index 4c4b662a..00000000 --- a/jsonschema-core.xml +++ /dev/null @@ -1,4406 +0,0 @@ - - - - - - - - - - - - - - -]> - - - - - - - - - - - JSON Schema: A Media Type for Describing JSON Documents - - -
- aaa@bzfx.net -
- - - - Postman -
- ben@jsonschema.dev - https://jsonschema.dev -
- - - -
- gregsdennis@yahoo.com - https://github.com/gregsdennis -
- - - - Internet Engineering Task Force - JSON - Schema - Hyper Schema - Hypermedia - - - - JSON Schema defines the media type "application/schema+json", a JSON-based format - for describing the structure of JSON data. - JSON Schema asserts what a JSON document must look like, - ways to extract information from it, - and how to interact with it. - The "application/schema-instance+json" media type provides additional - feature-rich integration with "application/schema+json" beyond what can be offered - for "application/json" documents. - - - - - The issues list for this draft can be found at - . - - - For additional information, see . - - - To provide feedback, use this issue tracker, the communication methods listed on the - homepage, or email the document editors. - - - - - -
- - JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema - is intended to define validation, documentation, hyperlink navigation, and interaction - control of JSON data. - - - This specification defines JSON Schema core terminology and mechanisms, including - pointing to another JSON Schema by reference, - dereferencing a JSON Schema reference, - specifying the dialect being used, - specifying a dialect's vocabulary requirements, - and defining the expected output. - - - Other specifications define the vocabularies that perform assertions about validation, - linking, annotation, navigation, and interaction. - -
- -
- - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. - - - - The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array", - "number", "string", "boolean", "true", "false", and "null" in this document are to - be interpreted as defined in RFC 8259. - -
- -
- - This document proposes a new media type "application/schema+json" to identify a JSON - Schema for describing JSON data. - It also proposes a further optional media type, "application/schema-instance+json", - to provide additional integration features. - JSON Schemas are themselves JSON documents. - This, and related specifications, define keywords allowing authors to describe JSON - data in several ways. - - - JSON Schema uses keywords to assert constraints on JSON instances or annotate those - instances with additional information. Additional keywords are used to apply - assertions and annotations to more complex JSON data structures, or based on - some sort of condition. - - - To facilitate re-use, keywords can be organized into vocabularies. A vocabulary - consists of a list of keywords, together with their syntax and semantics. - A dialect is defined as a set of vocabularies and their required support - identified in a meta-schema. - - - JSON Schema can be extended either by defining additional vocabularies, - or less formally by defining additional keywords outside of any vocabulary. - Unrecognized individual keywords simply have their values collected as annotations, - while the behavior with respect to an unrecognized vocabulary can be controlled - when declaring which vocabularies are in use. - - - This document defines a core vocabulary that MUST be supported by any - implementation, and cannot be disabled. Its keywords are each prefixed - with a "$" character to emphasize their required nature. This vocabulary - is essential to the functioning of the "application/schema+json" media - type, and is used to bootstrap the loading of other vocabularies. - - - Additionally, this document defines a RECOMMENDED vocabulary of keywords - for applying subschemas conditionally, and for applying subschemas to - the contents of objects and arrays. Either this vocabulary or one very - much like it is required to write schemas for non-trivial JSON instances, - whether those schemas are intended for assertion validation, annotation, - or both. While not part of the required core vocabulary, for maximum - interoperability this additional vocabulary is included in this document - and its use is strongly encouraged. - - - Further vocabularies for purposes such as structural validation or - hypermedia annotation are defined in other documents. These other - documents each define a dialect collecting the standard sets of - vocabularies needed to write schemas for that document's purpose. - -
- -
- -
- - A JSON document is an information resource (series of octets) described by the - application/json media type. - - - In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are - interchangeable because of the data model it defines in . - - - JSON Schema is only defined over JSON documents. However, any document or memory - structure that can be parsed into or processed according to the JSON Schema data - model can be interpreted against a JSON Schema, including media types like - CBOR. - -
- -
- - A JSON document to which a schema is applied is known as an "instance". - - - JSON Schema is defined over "application/json" or compatible documents, - including media types with the "+json" structured syntax suffix. - - - Among these, this specification defines the "application/schema-instance+json" - media type which defines handling for fragments in the IRI. - - -
- - JSON Schema interprets documents according to a data model. A JSON value - interpreted according to this data model is called an "instance". - - - An instance has one of six primitive types, and a range of possible values - depending on the type: - -
-
null
A JSON "null" value
-
boolean
A "true" or "false" value, from the JSON "true" or "false" value
-
object
An unordered set of properties mapping a string to an instance, from the JSON "object" value
-
array
An ordered list of instances, from the JSON "array" value
-
number
An arbitrary-precision, base-10 decimal number value, from the JSON "number" value
-
string
A string of Unicode code points, from the JSON "string" value
-
- - - Whitespace and formatting concerns, including different lexical - representations of numbers that are equal within the data model, are thus - outside the scope of JSON Schema. JSON Schema - vocabularies that wish - to work with such differences in lexical representations SHOULD define - keywords to precisely interpret formatted strings within the data model - rather than relying on having the original JSON representation Unicode - characters available. - - - Since an object cannot have two properties with the same key, behavior for a - JSON document that tries to define two properties with - the same key in a single object is undefined. - - - Note that JSON Schema vocabularies are free to define their own extended - type system. This should not be confused with the core data model types - defined here. As an example, "integer" is a reasonable type for a - vocabulary to define as a value for a keyword, but the data model - makes no distinction between integers and other numbers. - -
- -
- - Two JSON instances are said to be equal if and only if they are of the same type - and have the same value according to the data model. Specifically, this means: - -
    -
  • both are null; or
    • -
  • both are true; or
    • -
  • both are false; or
    • -
  • both are strings, and are the same codepoint-for-codepoint; or
    • -
  • both are numbers, and have the same mathematical value; or
    • -
  • both are arrays, and have an equal value item-for-item; or
    • -
  • both are objects, and each property in one has exactly one property with - a key equal to the other's, and that other property has an equal - value.
    • -
- - - Implied in this definition is that arrays must be the same length, - objects must have the same number of members, - properties in objects are unordered, - there is no way to define multiple properties with the same key, - and mere formatting differences (indentation, placement of commas, trailing - zeros) are insignificant. - -
- -
- - It is possible to use JSON Schema with a superset of the JSON Schema data model, - where an instance may be outside any of the six JSON data types. - - - In this case, annotations still apply; but most validation keywords will not be useful, - as they will always pass or always fail. - - - A custom vocabulary may define support for a superset of the core data model. - The schema itself may only be expressible in this superset; - for example, to make use of the "const" keyword. - -
-
- -
- - A JSON Schema document, or simply a schema, is a JSON document used to describe - an instance. - A schema can itself be interpreted as an instance, but SHOULD always be given - the media type "application/schema+json" rather than - "application/schema-instance+json". The "application/schema+json" media - type is defined to offer a superset of the - fragment identifier syntax and semantics provided by - "application/schema-instance+json". - - - A JSON Schema MUST be an object or a boolean. - -
- - Object properties that are applied to the instance are called keywords, - or schema keywords. Broadly speaking, keywords fall into one - of five categories: - -
-
identifiers
-
- control schema identification through setting a IRI - for the schema and/or changing how the base IRI is determined -
-
assertions
-
- produce a boolean result when applied to an instance -
-
annotations
-
- attach information to an instance for application use -
-
applicators
-
- apply one or more subschemas to a particular location - in the instance, and combine or modify their results -
-
reserved locations
-
- do not directly affect results, but reserve a place - for a specific purpose to ensure interoperability -
-
- - Keywords may fall into multiple categories, although applicators - SHOULD only produce assertion results based on their subschemas' - results. They should not define additional constraints independent - of their subschemas. - - - Keywords which are properties within the same schema object are referred to as adjacent keywords. - - - Extension keywords, meaning those defined outside of this document - and its companions, are free to define other behaviors as well. - - - A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. - The behavior of such keywords is governed by . - - - An empty schema is a JSON Schema with no properties. - -
-
- - The boolean schema values "true" and "false" are trivial schemas that - always produce themselves as assertion results, regardless of the - instance value. They never produce annotation results. - - - These boolean schemas exist to clarify schema author intent and - facilitate schema processing optimizations. They behave identically - to the following schema objects (where "not" is part of the - subschema application vocabulary defined in this document). - -
-
true
-
- Always passes validation, as if the empty schema {} -
- -
false
-
- Always fails validation, as if the schema { "not": {} } -
-
- - While the empty schema object is unambiguous, there are many - possible equivalents to the "false" schema. Using the boolean - values ensures that the intent is clear to both human readers - and implementations. - -
-
- - A schema vocabulary, or simply a vocabulary, is a set of keywords, - their syntax, and their semantics. A vocabulary is generally organized - around a particular purpose. Different uses of JSON Schema, such - as validation, hypermedia, or user interface generation, will - involve different sets of vocabularies. - - - Vocabularies are the primary unit of re-use in JSON Schema, as schema - authors can indicate what vocabularies are required or optional in - order to process the schema. Since vocabularies are identified by IRIs - in the meta-schema, generic implementations can load extensions to support - previously unknown vocabularies. While keywords can be supported outside - of any vocabulary, there is no analogous mechanism to indicate individual - keyword usage. - - - A schema vocabulary can be defined by anything from an informal description - to a standards proposal, depending on the audience and interoperability - expectations. In particular, in order to facilitate vocabulary use within - non-public organizations, a vocabulary specification need not be published - outside of its scope of use. - -
-
- - A schema that itself describes a schema is called a meta-schema. - Meta-schemas are used to validate JSON Schemas and specify which vocabularies - they are using. - - - Typically, a meta-schema will specify a set of vocabularies, and validate - schemas that conform to the syntax of those vocabularies. However, meta-schemas - and vocabularies are separate in order to allow meta-schemas to validate - schema conformance more strictly or more loosely than the vocabularies' - specifications call for. Meta-schemas may also describe and validate - additional keywords that are not part of a formal vocabulary. - -
-
- - A JSON Schema resource is a schema which is - canonically identified by an - absolute IRI. Schema resources MAY - also be identified by IRIs, including IRIs with fragments, - if the resulting secondary resource (as defined by - section 3.5 of RFC 3986) is identical - to the primary resource. This can occur with the empty fragment, - or when one schema resource is embedded in another. Any such IRIs - with fragments are considered to be non-canonical. - - - The root schema is the schema that comprises the entire JSON document - in question. The root schema is always a schema resource, where the - IRI is determined as described in . - - Note that documents that embed schemas in another format will not - have a root schema resource in this sense. Exactly how such usages - fit with the JSON Schema document and resource concepts will be - clarified in a future draft. - - - - Some keywords take schemas themselves, allowing JSON Schemas to be nested: - - - - In this example document, the schema titled "array item" is a subschema, - and the schema titled "root" is the root schema. - - - As with the root schema, a subschema is either an object or a boolean. - - - As discussed in , a JSON Schema document - can contain multiple JSON Schema resources. When used without qualification, - the term "root schema" refers to the document's root schema. In some - cases, resource root schemas are discussed. A resource's root schema - is its top-level schema object, which would also be a document root schema - if the resource were to be extracted to a standalone JSON Schema document. - - - Whether multiple schema resources are embedded or linked with a reference, - they are processed in the same way, with the same available behaviors. - -
-
- -
- -
- - In accordance with section 3.1 of RFC 6839, - the syntax and semantics of fragment identifiers specified for - any +json media type SHOULD be as specified for "application/json". - (At publication of this document, there is no fragment identification - syntax defined for "application/json".) - - - Additionally, the "application/schema+json" media type supports two - fragment identifier structures: plain names and JSON Pointers. - The "application/schema-instance+json" media type supports one - fragment identifier structure: JSON Pointers. - - - The use of JSON Pointers as IRI fragment identifiers is described in - RFC 6901. - For "application/schema+json", which supports two fragment identifier syntaxes, - fragment identifiers matching the JSON Pointer syntax, including the empty string, - MUST be interpreted as JSON Pointer fragment identifiers. - - - Per the W3C's - best practices for fragment identifiers, - plain name fragment identifiers in "application/schema+json" are reserved for referencing - locally named schemas. - - - Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("_"), - followed by any number of letters, digits ([0-9]), hyphens ("-"), - underscores ("_"), and periods ("."). This matches the US-ASCII part of XML's - NCName production, which allows for compatibility - with the recommended plain name syntax for - XML-based media types. - - - All fragment identifiers that do - not match the JSON Pointer syntax MUST be interpreted as - plain name fragment identifiers. - - - Defining and referencing a plain name fragment identifier within an - "application/schema+json" document are specified - in the "$anchor" keyword section. - -
- -
- -
- - An instance may be any valid JSON value as defined by JSON. - JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON - value, including, for example, null. - -
- -
- - JSON Schema is programming language agnostic, and supports the full range of - values described in the data model. - Be aware, however, that some languages and JSON parsers may not be able to - represent in memory the full range of values describable by JSON. - -
- -
- - Some programming languages and parsers use different internal representations - for floating point numbers than they do for integers. - - - For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional - part. - -
- -
- - Keywords MAY use regular expressions to express constraints, or constrain - the instance value to be a regular expression. - These regular expressions SHOULD be valid according to the regular expression - dialect described in ECMA-262, section 21.2.1. - - - Unless otherwise specified by a keyword, regular expressions MUST NOT be - considered to be implicitly anchored at either end. All regular expression - keywords in this specification and its companion documents are un-anchored. - - - Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide - Unicode support, or processed in such a way which provides Unicode support as - defined by ECMA-262. - - - Furthermore, given the high disparity in regular expression constructs support, - schema authors SHOULD limit themselves to the following regular expression - tokens: - -
    -
  • individual Unicode characters, as defined by the JSON specification;
    • -
  • simple character classes ([abc]), range character classes ([a-z]);
    • -
  • complemented character classes ([^abc], [^a-z]);
    • -
  • simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or - one), and their lazy versions ("+?", "*?", "??");
    • -
  • range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at - most y, occurrences), {x,} (x occurrences or more), and their lazy - versions;
    • -
  • the beginning-of-input ("^") and end-of-input ("$") anchors;
    • -
  • simple grouping ("(...)") and alternation ("|").
    • -
- - - Finally, implementations MUST NOT take regular expressions to be - anchored, neither at the beginning nor at the end. This means, for instance, - the pattern "es" matches "expression". - -
- -
- - Additional schema keywords and schema vocabularies MAY be defined - by any entity. Save for explicit agreement, schema authors SHALL NOT - expect these additional keywords and vocabularies to be supported by - implementations that do not explicitly document such support. - - - Implementations MAY provide the ability to register or load handlers - for vocabularies that they do not support directly. The exact mechanism - for registering and implementing such handlers is implementation-dependent. - - -
- - The values of keywords which begin with "x-" MUST be collected as annotations. - - - Keywords which begin with "x-" symbol MUST NOT affect evaluation - of a schema in any way other than annotation collection. - - - Consequently, the "x-" prefix is reserved for this purpose, and - extension vocabularies MUST NOT define any keywords which begin - with this prefix. - -
- -
- - Implementations SHOULD treat keywords they do not recognize, or that - they recognize but do not support, as annotations, where the value of - the keyword is the value of the annotation. Whether an implementation - collects these annotations or not, they MUST otherwise ignore the keywords. - -
-
- -
- -
- - JSON Schema keywords fall into several general behavior categories. - Assertions validate that an instance satisfies constraints, producing - a boolean result. Annotations attach information that applications - may use in any way they see fit. - Applicators apply subschemas to parts of the instance and combine - their results. - - - Extension keywords SHOULD stay within these categories, keeping in mind - that annotations in particular are extremely flexible. Complex behavior - is usually better delegated to applications on the basis of annotation - data than implemented directly as schema keywords. However, extension - keywords MAY define other behaviors for specialized purposes. - - - Evaluating an instance against a schema involves processing all of the - keywords in the schema against the appropriate locations within the instance. - Typically, applicator keywords are processed until a schema object with no - applicators (and therefore no subschemas) is reached. The appropriate - location in the instance is evaluated against the assertion and - annotation keywords in the schema object. The interactions of those - keyword results to produce the schema object results are governed by - , while the - relationship of subschema results to the results of the applicator - keyword that applied them is described by . - - - Evaluation of a parent schema object can complete once all of its - subschemas have been evaluated, although in some circumstances evaluation - may be short-circuited due to assertion results. When annotations are - being collected, some assertion result short-circuiting is not possible - due to the need to examine all subschemas for annotation collection, including - those that cannot further change the assertion result. - -
- - While most JSON Schema keywords can be evaluated on their own, - or at most need to take into account the values or results of - adjacent keywords in the same schema object, a few have more - complex behavior. - - - The lexical scope of a keyword is determined by the nested JSON - data structure of objects and arrays. The largest such scope - is an entire schema document. The smallest scope is a single - schema object with no subschemas. - - - Keywords MAY be defined with a partial value, such as a IRI-reference, - which must be resolved against another value, such as another - IRI-reference or a full IRI, which is found through the lexical - structure of the JSON document. The "$id", "$ref", and - "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema - keyword, are examples of this sort of behavior. - - - Note that some keywords, such as "$schema", apply to the lexical - scope of the entire schema resource, and therefore MUST only - appear in a schema resource's root schema. - - - Other keywords may take into account the dynamic scope that - exists during the evaluation of a schema, typically together - with an instance document. - The outermost dynamic scope is the schema object at - which processing begins, even if it is not a schema resource root. - The path from this root schema to any particular keyword (that - includes any "$ref" and "$dynamicRef" keywords that may have - been resolved) is considered the keyword's "evaluation path." - - - Lexical and dynamic scopes align until a reference keyword - is encountered. While following the reference keyword moves processing - from one lexical scope into a different one, from the perspective - of dynamic scope, following a reference is no different from descending - into a subschema present as a value. A keyword on the far side of - that reference that resolves information through the dynamic scope - will consider the originating side of the reference to be their - dynamic parent, rather than examining the local lexically enclosing parent. - - - The concept of dynamic scope is primarily used with "$dynamicRef" and - "$dynamicAnchor", and should be considered an advanced feature - and used with caution when defining additional keywords. It also appears - when reporting errors and collected annotations, as it may be possible - to revisit the same lexical scope repeatedly with different dynamic - scopes. In such cases, it is important to inform the user of the - evaluation path that produced the error or annotation. - -
-
- - Keyword behavior MAY be defined in terms of the annotation results - of subschemas and/or adjacent keywords - (keywords within the same schema object) and their subschemas. - Such keywords MUST NOT result in a circular dependency. - Keywords MAY modify their behavior based on the presence or absence - of another keyword in the same - schema object. - -
-
- - A missing keyword MUST NOT produce a false assertion result, MUST - NOT produce annotation results, and MUST NOT cause any other schema - to be evaluated as part of its own behavioral definition. - However, given that missing keywords do not contribute annotations, - the lack of annotation results may indirectly change the behavior - of other keywords. - - - In some cases, the missing keyword assertion behavior of a keyword is - identical to that produced by a certain value, and keyword definitions - SHOULD note such values where known. However, even if the value which - produces the default behavior would produce annotation results if - present, the default behavior still MUST NOT result in annotations. - - - Because annotation collection can add significant cost in terms of both - computation and memory, implementations MAY opt out of this feature. - Keywords that are specified in terms of collected annotations SHOULD - describe reasonable alternate approaches when appropriate. - This approach is demonstrated by the - "" and - "" keywords in this - document. - - - Note that when no such alternate approach is possible for a keyword, - implementations that do not support annotation collections will not - be able to support those keywords or vocabularies that contain them. - -
-
- - Identifiers define IRIs for a schema, or affect how such IRIs are - resolved in references, or both. - The Core vocabulary defined in this document defines several - identifying keywords, most notably "$id". - - - Canonical schema IRIs MUST NOT change while processing an instance, but - keywords that affect IRI-reference resolution MAY have behavior that - is only fully determined at runtime. - - - While custom identifier keywords are possible, vocabulary designers should - take care not to disrupt the functioning of core keywords. For example, - the "$dynamicAnchor" keyword in this specification limits its IRI resolution - effects to the matching "$dynamicRef" keyword, leaving the behavior - of "$ref" undisturbed. - -
-
- - Applicators allow for building more complex schemas than can be accomplished - with a single schema object. Evaluation of an instance against a - schema document begins by applying - the root schema to the complete instance - document. From there, keywords known as applicators are used to determine - which additional schemas are applied. Such schemas may be applied in-place - to the current location, or to a child location. - - - The schemas to be applied may be present as subschemas comprising all or - part of the keyword's value. Alternatively, an applicator may refer to - a schema elsewhere in the same schema document, or in a different one. - The mechanism for identifying such referenced schemas is defined by the - keyword. - - - Applicator keywords also define how subschema or referenced schema - boolean assertion - results are modified and/or combined to produce the boolean result - of the applicator. Applicators may apply any boolean logic operation - to the assertion results of subschemas, but MUST NOT introduce new - assertion conditions of their own. - - - Annotation results from subschemas - are preserved in accordance with so that applications - can decide how to interpret multiple values. Applicator keywords - do not play a direct role in this preservation. - -
- - As noted in , an applicator keyword may - refer to a schema to be applied, rather than including it as a - subschema in the applicator's value. In such situations, the - schema being applied is known as the referenced schema, while - the schema containing the applicator keyword is the referencing schema. - - - While root schemas and subschemas are static concepts based on a - schema's position within a schema document, referenced and referencing - schemas are dynamic. Different pairs of schemas may find themselves - in various referenced and referencing arrangements during the evaluation - of an instance against a schema. - - - For some by-reference applicators, such as - "$ref", the referenced schema can be determined - by static analysis of the schema document's lexical scope. Others, - such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic - scoping, and therefore only be resolvable in the process of evaluating - the schema with an instance. - -
-
- -
- - JSON Schema can be used to assert constraints on a JSON document, which - either passes or fails the assertions. This approach can be used to validate - conformance with the constraints, or document what is needed to satisfy them. - - - JSON Schema implementations produce a single boolean result when evaluating - an instance against schema assertions. - - - An instance can only fail an assertion that is present in the schema. - - -
- - Most assertions only constrain values within a certain - primitive type. When the type of the instance is not of the type - targeted by the keyword, the instance is considered to conform - to the assertion. - - - For example, the "maxLength" keyword from the companion - validation vocabulary: - will only restrict certain strings - (that are too long) from being valid. If the instance is a number, - boolean, null, array, or object, then it is valid against this assertion. - - - This behavior allows keywords to be used more easily with instances - that can be of multiple primitive types. The companion validation - vocabulary also includes a "type" keyword which can independently - restrict the instance to one or more primitive types. This allows - for a concise expression of use cases such as a function that might - return either a string of a certain length or a null value: - - - - If "maxLength" also restricted the instance type to be a string, - then this would be substantially more cumbersome to express because - the example as written would not actually allow null values. - Each keyword is evaluated separately unless explicitly specified - otherwise, so if "maxLength" restricted the instance to strings, - then including "null" in "type" would not have any useful effect. - -
-
- -
- - JSON Schema can annotate an instance with information, whenever the instance - validates against the schema object containing the annotation, and all of its - parent schema objects. The information can be a simple value, or can be - calculated based on the instance contents. - - - Annotations are attached to specific locations in an instance. - Since many subschemas can be applied to any single - location, applications may need to decide how to handle differing - annotation values being attached to the same instance location by - the same schema keyword in different schema objects. - - - Unlike assertion results, annotation data can take a wide variety of forms, - which are provided to applications to use as they see fit. JSON Schema - implementations are not expected to make use of the collected information - on behalf of applications. - - - Unless otherwise specified, the value of an annotation keyword - is the keyword's value. However, other behaviors are possible. - For example, JSON Hyper-Schema's - "links" keyword is a complex annotation that produces a value based - in part on the instance data. - - - While "short-circuit" evaluation is possible for assertions, collecting - annotations requires examining all schemas that apply to an instance - location, even if they cannot change the overall assertion result. - The only exception is that subschemas of a schema object that has - failed validation MAY be skipped, as annotations are not retained - for failing schemas. - - -
- - Annotations are collected by keywords that explicitly define - annotation-collecting behavior. Note that boolean schemas cannot - produce annotations as they do not make use of keywords. - - - A collected annotation MUST include the following information: - -
    -
  • - The name of the keyword that produces the annotation -
    • -
  • - The instance location to which it is attached, as a JSON Pointer -
    • -
  • - The evaluation path, indicating how reference keywords - such as "$ref" were followed to reach the absolute schema location. -
    • -
  • - The absolute schema location of the attaching keyword, as a IRI. - This MAY be omitted if it is the same as the evaluation path - from above. -
    • -
  • - The attached value(s) -
    • -
-
- - Applications MAY make decisions on which of multiple annotation values - to use based on the schema location that contributed the value. - This is intended to allow flexible usage. Collecting the schema location - facilitates such usage. - - - For example, consider this schema, which uses annotations and assertions from - the Validation specification: - - - Note that some lines are wrapped for clarity. - - - - In this example, both Feature A and Feature B make use of the re-usable - "enabledToggle" schema. That schema uses the "title", "description", - and "default" annotations. Therefore the application has to decide how - to handle the additional "default" value for Feature A, and the additional - "description" value for Feature B. - - - The application programmer and the schema author need to agree on the - usage. For this example, let's assume that they agree that the most - specific "default" value will be used, and any additional, more generic - "default" values will be silently ignored. Let's also assume that they - agree that all "description" text is to be used, starting with the most - generic, and ending with the most specific. This requires the schema - author to write descriptions that work when combined in this way. - - - The application can use the evaluation path to determine which - values are which. The values in the feature's immediate "enabled" - property schema are more specific, while the values under the re-usable - schema that is referenced to with "$ref" are more generic. The evaluation - path will show whether each value was found by crossing a - "$ref" or not. - - - Feature A will therefore use a default value of true, while Feature B - will use the generic default value of null. Feature A will only - have the generic description from the "enabledToggle" schema, while - Feature B will use that description, and also append its locally - defined description that explains how to interpret a null value. - - - Note that there are other reasonable approaches that a different application - might take. For example, an application may consider the presence of - two different values for "default" to be an error, regardless of their - schema locations. - -
-
- - Schema objects that produce a false assertion result MUST NOT - produce any annotation results, whether from their own keywords - or from keywords in subschemas. - - - Note that the overall schema results may still include annotations - collected from other schema locations. Given this schema: - - - - Against the instance "This is a string", the - title annotation "Integer Value" is discarded because the type assertion - in that schema object fails. The title annotation "String Value" - is kept, as the instance passes the string type assertions. - -
-
-
-
- - A fourth category of keywords simply reserve a location to hold re-usable - components or data of interest to schema authors that is not suitable - for re-use. These keywords do not affect validation or annotation results. - Their purpose in the core vocabulary is to ensure that locations are - available for certain purposes and will not be redefined by extension - keywords. - - - While these keywords do not directly affect results, as explained in - unrecognized - extension keywords that reserve locations for re-usable schemas may have - undesirable interactions with references in certain circumstances. - -
-
- - While none of the vocabularies defined as part of this or the associated documents - define a keyword which may target and/or load instance data, it is possible that - other vocabularies may wish to do so. - - - Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to examine - parts of an instance outside the current evaluation location. - - - Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD - default to using the current location if a default is desireable. - -
-
-
- - Keywords declared in this section, which all begin with "$", make up - the JSON Schema Core vocabulary. These keywords are either required in - order to process any schema or meta-schema, including those split across - multiple documents, or exist to reserve keywords for purposes that - require guaranteed interoperability. - - - The Core vocabulary MUST be considered mandatory at all times, in order - to bootstrap the processing of further vocabularies. Meta-schemas - that use the "$vocabulary" keyword - to declare the vocabularies in use MUST explicitly list the Core vocabulary, - which MUST have a value of true indicating that it is required. - - - The behavior of a false value for this vocabulary (and only this - vocabulary) is undefined, as is the behavior when "$vocabulary" - is present but the Core vocabulary is not included. However, it - is RECOMMENDED that implementations detect these cases and raise - an error when they occur. It is not meaningful to declare that - a meta-schema optionally uses Core. - - - Meta-schemas that do not use "$vocabulary" MUST be considered to - require the Core vocabulary as if its IRI were present with a value of true. - - - The current IRI for the Core vocabulary is: - <https://json-schema.org/draft/next/vocab/core>. - - - The current IRI for the corresponding meta-schema is: - . - - - The "$" prefix is reserved for use by the Core vocabulary. - Vocabulary extensions MUST NOT define new keywords that begin with "$". - - -
- - Two concepts, meta-schemas and vocabularies, are used to inform an implementation - how to interpret a schema. Every schema has a meta-schema, which can be declared - using the "$schema" keyword. - - - The meta-schema serves two purposes: - -
-
Declaring the vocabularies in use
-
- The "$vocabulary" keyword, when it appears in a meta-schema, declares - which vocabularies are available to be used in schemas that refer - to that meta-schema. Vocabularies define keyword semantics, - as well as their general syntax. -
-
Describing valid schema syntax
-
- A schema MUST successfully validate against its meta-schema, which - constrains the syntax of the available keywords. The syntax described - is expected to be compatible with the vocabularies declared; while - it is possible to describe an incompatible syntax, such a meta-schema - would be unlikely to be useful. -
-
- - Meta-schemas are separate from vocabularies to allow for - vocabularies to be combined in different ways, and for meta-schema authors - to impose additional constraints such as forbidding certain keywords, or - performing unusually strict syntactical validation, as might be done - during a development and testing cycle. Each vocabulary typically identifies - a meta-schema consisting only of the vocabulary's keywords. - - - Meta-schema authoring is an advanced usage of JSON Schema, so the design of - meta-schema features emphasizes flexibility over simplicity. - -
- - The "$schema" keyword is both used as a JSON Schema dialect identifier and - as the identifier of a resource which is itself a JSON Schema, which describes the - set of valid schemas written for this particular dialect. - - - The value of this keyword MUST be a IRI - (containing a scheme) and this IRI MUST be normalized. - The current schema MUST be valid against the meta-schema identified by this IRI. - - - If this IRI identifies a retrievable resource, that resource SHOULD be of - media type "application/schema+json". - - - The "$schema" keyword SHOULD be used in the document root schema object, - and MAY be used in the root schema objects of embedded schema resources. - It MUST NOT appear in non-resource root schema objects. If absent from - the document root schema, the resulting behavior is implementation-defined, - but MUST fall within the following options: -
    -
  • Refuse to process the schema, as with unsupported required - vocabularies
    • -
  • Assume a specific, documented meta-schema
    • -
  • Document the process by which it examines the schema and determines - which of a specific set of meta-schemas to assume
    • -
- - - Values for this property are defined elsewhere in this and other documents, - and by other parties. - -
-
- - The "$vocabulary" keyword is used in meta-schemas to identify the - vocabularies available for use in schemas described by that meta-schema, - and whether each vocabulary is required or optional. Together, this - information forms a dialect. - - - The value of this keyword MUST be an object. The property names in the - object MUST be IRIs (containing a scheme) and each IRI MUST be normalized. - Each IRI that appears as a property name identifies a specific set of - keywords and their semantics. - - - The IRI MAY be a URL, but the nature of the retrievable resource is - currently undefined, and reserved for future use. Vocabulary authors - MAY use the URL of the vocabulary specification, in a human-readable - media type such as text/html or text/plain, as the vocabulary IRI. - - Vocabulary documents may be added in forthcoming drafts. - For now, identifying the keyword set is deemed sufficient as that, - along with meta-schema validation, is how the current "vocabularies" - work today. Any future vocabulary document format will be specified - as a JSON document, so using text/html or other non-JSON formats - in the meantime will not produce any future ambiguity. - - - - The values of the object properties MUST be booleans. - If the value is true, then the vocabulary MUST be considered to be required. - If the value is false, then the vocabulary MUST be considered to be optional. - -
- - A schema is said to use a dialect and its constituent vocabularies if it is - associated with a meta-schema defining the dialect with "$vocabulary", - either through "$schema", through appropriately defined media type parameters - or link relation types, or through documented default implementation-defined - behavior in the absence of an explicit meta-schema. If a meta-schema - does not contain "$vocabulary", the set of vocabularies in use is determined - according to . - - - Any vocabulary in use by a schema and understood by the implementation - MUST be processed in a manner consistent with the semantic definitions - contained within the vocabulary, regardless of whether that vocabulary - is required or optional. - - - Any vocabulary that is not present in "$vocabulary" MUST NOT be made - available for use in schemas described by that meta-schema, except for - the core vocabulary as specified by the introduction to - . - - - Implementations that do not support a vocabulary required by a schema - MUST refuse to process that schema. - - - Implementations that do not support a vocabulary that is optionally used - by a schema SHOULD proceed with processing the schema. The keywords will - be considered to be unrecognized keywords as addressed by - . Note that since - the recommended behavior for such keywords is to collect them as - annotations, vocabularies consisting only of annotations will have - the same behavior when used optionally whether the implementation - supports them or not. This allows annotation-only vocabularies to - be supported without custom code, even in implementations that do - not support providing custom code for extension vocabularies. - -
-
- - The "$vocabulary" keyword SHOULD be used in the root schema of any schema - resource intended for use as a meta-schema. It MUST NOT appear in subschemas. - - - The "$vocabulary" keyword MUST be ignored in schema resources that - are not being processed as a meta-schema. This allows validating - a meta-schema M against its own meta-schema M' without requiring - the validator to understand the vocabularies declared by M. - -
-
- - Keywords from different vocabularies, as well as non-vocabulary - extension keywords, can have identical names. These are not - considered to be the same keyword from the perspective of - enabling or disabling them through "$vocabulary". - - - In particular the keywords defined in this specification and its - companion documents MUST be considered to be vocabulary keywords, - with availability governed by "$vocabulary" even in implementations - that do not support any extension vocabularies. - - - Guidance regarding vocabularies with identically-named keywords is provided - in . - -
-
- - If "$vocabulary" is absent, an implementation MAY determine - behavior based on the meta-schema if it is recognized from the - IRI value of the referring schema's "$schema" keyword. - This is how behavior (such as Hyper-Schema usage) has been - recognized prior to the existence of vocabularies. - - - If the meta-schema, as referenced by the schema, is not recognized, - or is missing, then the behavior is implementation-defined. - If the implementation - proceeds with processing the schema, it MUST assume the use of the - core vocabulary. If the implementation is built for a specific purpose, - then it SHOULD assume the use of all of the most relevant vocabularies - for that purpose. - - - For example, an implementation that is a validator - SHOULD assume the use of all vocabularies in this - specification and the companion Validation specification. - -
-
- - Note that the processing restrictions on "$vocabulary" mean that - meta-schemas that reference other meta-schemas using "$ref" or - similar keywords do not automatically inherit the vocabulary - declarations of those other meta-schemas. All such declarations - must be repeated in the root of each schema document intended - for use as a meta-schema. This is demonstrated in - the example meta-schema. - - This requirement allows implementations to find all vocabulary - requirement information in a single place for each meta-schema. - As schema extensibility means that there are endless potential - ways to combine more fine-grained meta-schemas by reference, - requiring implementations to anticipate all possibilities and - search for vocabularies in referenced meta-schemas would - be overly burdensome. - - -
-
-
- - Updated vocabulary and meta-schema IRIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider IRIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
-
- -
- - To differentiate between schemas in a vast ecosystem, schemas are - identified by IRI, and can embed references - to other schemas by specifying their IRI. - - - Several keywords can accept a relative IRI-reference, - or a value used to construct a relative IRI-reference. For these keywords, - it is necessary to establish a base IRI in order to resolve the reference. - - -
- - The "$id" keyword identifies a schema resource with its - canonical IRI. - - - Note that this IRI is an identifier and not necessarily a network locator. - In the case of a network-addressable URL, a schema need not be downloadable - from its canonical IRI. - - - If present, the value for this keyword MUST be a string, and MUST represent a - valid IRI-reference. This IRI-reference - SHOULD be normalized, and MUST resolve to an - absolute-IRI (without a fragment). - - - The resulting absolute-IRI serves as the base IRI for relative IRI-references - in keywords within the schema resource, in accordance with - RFC 3987 section 6.5 and - RFC 3986 section 5.1.1 regarding base IRIs - embedded in content. - - - The presence of "$id" in a subschema indicates that the subschema constitutes - a distinct schema resource within a single schema document. Furthermore, - in accordance with RFC 3987 section 6.5 and - RFC 3986 section 5.1.2 regarding - encapsulating entities, if an "$id" in a subschema is a relative - IRI-reference, the base IRI for resolving that reference is the IRI of - the parent schema resource. Note that an "$id" consisting of an empty IRI or - of the empty fragment only will result in the embedded resource having - the same IRI as the encapsulating resource, which SHOULD be considered - an error per . - - - If no parent schema object explicitly identifies itself as a resource - with "$id", the base IRI is that of the entire document, as established - by the steps given in the previous section. - -
- - The root schema of a JSON Schema document SHOULD contain an "$id" keyword - with an absolute-IRI (containing a scheme, - but no fragment). - -
-
-
- - Using JSON Pointer fragments requires knowledge of the structure of the schema. - When writing schema documents with the intention to provide re-usable - schemas, it may be preferable to use a plain name fragment that is not tied to - any particular structural location. This allows a subschema to be relocated - without requiring JSON Pointer references to be updated. - - - The "$anchor" and "$dynamicAnchor" keywords are used to specify such - fragments. They are identifier keywords that can only be used to create - plain name fragments, rather than absolute IRIs as seen with "$id". - - - The base IRI to which the resulting fragment is appended is the canonical - IRI of the schema resource containing the "$anchor" or "$dynamicAnchor" - in question. As discussed in the previous section, this is either the - nearest "$id" in the same or parent schema object, - or the base IRI for the document as determined according to - RFC 3987 and - RFC 3986. - - - Separately from the usual usage of IRIs, "$dynamicAnchor" - indicates that the fragment is an extension point when used with - the "$dynamicRef" keyword. This low-level, advanced feature - makes it easier to extend recursive schemas such as the meta-schemas, - without imposing any particular semantics on that extension. - See the section on "$dynamicRef" - for details. - - - In most cases, the normal fragment behavior both suffices and - is more intuitive. Therefore it is RECOMMENDED that "$anchor" - be used to create plain name fragments unless there is a clear - need for "$dynamicAnchor". - - - If present, the value of these keywords MUST be a string and MUST conform - to the plain name fragment identifier syntax defined in - . - - Note that the anchor string does not include the "#" character, - as it is not a IRI-reference. An "$anchor": "foo" becomes the - fragment "#foo" when used in a IRI. See below for full examples. - - -
- -
- - A schema MAY (and likely will) have multiple IRIs, but there is no way - for an IRI to identify more than one schema. When multiple schemas - attempt to identify as the same IRI through the use of "$id", "$anchor", - "$dynamicAnchor", or any other mechanism, implementations SHOULD raise - an error condition. Otherwise the result is undefined, and even if - documented will not be interoperable. - -
- -
- - Several keywords can be used to reference a schema which is to be applied to the - current instance location. "$ref" and "$dynamicRef" are applicator - keywords, applying the referenced schema to the instance. - - - As the values of "$ref" and "$dynamicRef" are IRI References, this allows - the possibility to externalise or divide a schema across multiple files, - and provides the ability to validate recursive structures through - self-reference. - - - The resolved IRI produced by these keywords is not necessarily a network - locator, only an identifier. A schema need not be downloadable from the - address if it is a network-addressable URL, and implementations SHOULD NOT - assume they should perform a network operation when they encounter - a network-addressable IRI. - - -
- - The "$ref" keyword is an applicator that is used to reference a statically - identified schema. Its results are the results of the referenced schema. - - Note that this definition of how the results are determined means that - other keywords can appear alongside of "$ref" in the same schema object. - - - - The value of the "$ref" keyword MUST be a string which is a IRI-Reference. - Resolved against the current IRI base, it produces the IRI of the schema - to apply. This resolution is safe to perform on schema load, as the - process of evaluating an instance cannot change how the reference resolves. - -
- -
- - The "$dynamicRef" keyword is an applicator that allows for deferring the - full resolution until runtime, at which point it is resolved each time it is - encountered while evaluating an instance. - - - Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative - extension mechanism that is primarily useful with recursive schemas - (schemas that reference themselves). The extension point is defined with - "$dynamicAnchor" and only exhibits runtime dynamic behavior when referenced - with "$dynamicRef". - - - The value of the "$dynamicRef" property MUST be a string which is a - IRI-Reference that contains a valid plain name - fragment. Resolved against the current IRI base, it indicates - the schema resource used as the starting point for runtime resolution. - This initial resolution is safe to perform on schema load. - - - The schema to apply is the outermost schema resource in the - dynamic scope that defines a - "$dynamicAnchor" that matches the plain name fragment in the initially - resolved IRI. - - - For a full example using these keyword, see . - - The difference between the hyper-schema meta-schema in pre-2019 - drafts and an this draft dramatically demonstrates the utility - of these keywords. - - -
- -
- -
- - The "$defs" keyword reserves a location for schema - authors to inline re-usable JSON Schemas into a more general schema. - The keyword does not directly affect the validation result. - - - This keyword's value MUST be an object. - Each member value of this object MUST be a valid JSON Schema. - - - As an example, here is a schema describing an array of positive - integers, where the positive integer constraint is a subschema in - "$defs": - - -
-
- -
- - This keyword reserves a location for comments from schema authors - to readers or maintainers of the schema. - - - The value of this keyword MUST be a string. Implementations MUST NOT present this - string to end users. Tools for editing schemas SHOULD support displaying and - editing this keyword. The value of this keyword MAY be used in debug or error - output which is intended for developers making use of schemas. - - - Schema vocabularies SHOULD allow "$comment" within any object containing - vocabulary keywords. Implementations MAY assume "$comment" is allowed - unless the vocabulary specifically forbids it. Vocabularies MUST NOT - specify any effect of "$comment" beyond what is described in this - specification. - - - Tools that translate other media types or programming languages - to and from application/schema+json MAY choose to convert that media type or - programming language's native comments to or from "$comment" values. - The behavior of such translation when both native comments and "$comment" - properties are present is implementation-dependent. - - - Implementations MAY strip "$comment" values at any point during processing. - In particular, this allows for shortening schemas when the size of deployed - schemas is a concern. - - - Implementations MUST NOT take any other action based on the presence, absence, - or contents of "$comment" properties. In particular, the value of "$comment" - MUST NOT be collected as an annotation result. - -
-
- -
- - -
-
- - RFC 3987 Section 6.5 and - RFC 3986 Section 5.1 defines how to determine the - default base IRI of a document. - - - Informatively, the initial base IRI of a schema is the IRI at which it was - found, whether that was a network location, a local filesystem, or any other - situation identifiable by a IRI of any known scheme. - - - If a schema document defines no explicit base IRI with "$id" - (embedded in content), the base IRI is that determined per - RFC 3987 Section 6.5 and - RFC 3986 section 5. - - - If no source is known, or no IRI scheme is known for the source, a suitable - implementation-specific default IRI MAY be used as described in - RFC 3987 Section 6.5 and - RFC 3986 Section 5.1.4. It is RECOMMENDED - that implementations document any default base IRI that they assume. - - - If a schema object is embedded in a document of another media type, then - the initial base IRI is determined according to the rules of that - media type. - - - Unless the "$id" keyword described in an earlier section is present in the - root schema, this base IRI SHOULD be considered the canonical IRI of the - schema document's root schema resource. - -
- -
- - The use of IRIs to identify remote schemas does not necessarily mean anything is downloaded, - but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, - and the IRIs that identify them. - - - When schemas are downloaded, - for example by a generic user-agent that does not know until runtime which schemas to download, - see Usage for Hypermedia. - - - Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary - schema and/or automatically associate a schema's "$id"-given IRI, depending - on the trust that the validator has in the schema. Such IRIs and schemas - can be supplied to an implementation prior to processing instances, or may - be noted within a schema document as it is processed, producing associations - as shown in . - -
- -
- - Implementations MUST recognize a schema as a meta-schema if it - is being examined because it was identified as such by another - schema's "$schema" keyword. This means that a single schema - document might sometimes be considered a regular schema, and - other times be considered a meta-schema. - - - In the case of examining a schema which is its own meta-schema, - when an implementation begins processing it as a regular schema, - it is processed under those rules. However, when loaded a second - time as a result of checking its own "$schema" value, it is treated - as a meta-schema. So the same document is processed both ways in - the course of one session. - - - Implementations MAY allow a schema to be explicitly passed as a meta-schema, - for implementation-specific purposes, such as pre-loading a commonly - used meta-schema and checking its vocabulary support requirements - up front. Meta-schema authors MUST NOT expect such features to be - interoperable across implementations. - -
-
- -
- - Schemas can be identified by any IRI that has been given to them, including - a JSON Pointer or their IRI given directly by "$id". In all cases, - dereferencing a "$ref" reference involves first resolving its value as a - IRI reference against the current base IRI per - RFC 3986. - - - If the resulting IRI identifies a schema within the current document, or - within another schema document that has been made available to the implementation, - then that schema SHOULD be used automatically. - - - For example, consider this schema: - - - - - When an implementation encounters the <#/$defs/single> schema, - it resolves the "$anchor" value as a fragment name against the current - base IRI to form <https://example.net/root.json#item>. - - - When an implementation then looks inside the <#/items> schema, it - encounters the <#item> reference, and resolves this to - <https://example.net/root.json#item>, which it has seen defined in - this same document and can therefore use automatically. - - - When an implementation encounters the reference to "other.json", it resolves - this to <https://example.net/other.json>, which is not defined in this - document. If a schema with that identifier has otherwise been supplied to - the implementation, it can also be used automatically. - - What should implementations do when the referenced schema is not known? - Are there circumstances in which automatic network dereferencing is - allowed? A same origin policy? A user-configurable option? In the - case of an evolving API described by Hyper-Schema, it is expected that - new schemas will be added to the system dynamically, so placing an - absolute requirement of pre-loading schema documents is not feasible. - - - -
- - Since JSON Pointer IRI fragments are constructed based on the structure - of the schema document, an embedded schema resource and its subschemas - can be identified by JSON Pointer fragments relative to either its own - canonical IRI, or relative to any containing resource's IRI. - - - Conceptually, a set of linked schema resources should behave - identically whether each resource is a separate document connected with - schema references, or is structured as - a single document with one or more schema resources embedded as - subschemas. - - - Since IRIs involving JSON Pointer fragments relative to the parent - schema resource's IRI cease to be valid when the embedded schema - is moved to a separate document and referenced, applications and schemas - SHOULD NOT use such IRIs to identify embedded schema resources or - locations within them. - - - Consider the following schema document that contains another - schema resource embedded within it: - - - - The IRI "https://example.com/foo#/items" points to the "items" schema, - which is an embedded resource. The canonical IRI of that schema - resource, however, is "https://example.com/bar". - - - For the "additionalProperties" schema within that embedded resource, - the IRI "https://example.com/foo#/items/additionalProperties" points - to the correct object, but that object's IRI relative to its resource's - canonical IRI is "https://example.com/bar#/additionalProperties". - - - Now consider the following two schema resources linked by reference - using a IRI value for "$ref": - - - - - Here we see that "https://example.com/bar#/additionalProperties", - using a JSON Pointer fragment appended to the canonical IRI of - the "bar" schema resource, is still valid, while - "https://example.com/foo#/items/additionalProperties", which relied - on a JSON Pointer fragment appended to the canonical IRI of the - "foo" schema resource, no longer resolves to anything. - - - Note also that "https://example.com/foo#/items" is valid in both - arrangements, but resolves to a different value. This IRI ends up - functioning similarly to a retrieval IRI for a resource. While this IRI - is valid, it is more robust to use the "$id" of the embedded or referenced - resource unless it is specifically desired to identify the object containing - the "$ref" in the second (non-embedded) arrangement. - - - An implementation MAY choose not to support addressing schema resource - contents by IRIs using a base other than the resource's canonical IRI, - plus a JSON Pointer fragment relative to that base. Therefore, schema - authors SHOULD NOT rely on such IRIs, as using them may reduce interoperability. - - This is to avoid requiring implementations to keep track of a whole - stack of possible base IRIs and JSON Pointer fragments for each, - given that all but one will be fragile if the schema resources - are reorganized. Some - have argued that this is easy so there is - no point in forbidding it, while others have argued that it complicates - schema identification and should be forbidden. Feedback on this - topic is encouraged. - After some discussion, we feel that we need to remove the use of - "canonical" in favour of talking about JSON Pointers which reference - across schema resource boundaries as undefined or even forbidden behavior - (https://github.com/json-schema-org/json-schema-spec/issues/937, - https://github.com/json-schema-org/json-schema-spec/issues/1183) - - - - Further examples of such non-canonical IRI construction, as well as - the appropriate canonical IRI-based fragments to use instead, - are provided in . - -
-
- -
- - A Compound Schema Document is defined as a JSON document (sometimes called a "bundled" schema) - which has multiple embedded JSON Schema Resources bundled into the same document to - ease transportation. - - - Each embedded Schema Resource MUST be treated as an individual Schema Resource, following standard - schema loading and processing requirements, including determining vocabulary support. - -
- - The bundling process for creating a Compound Schema Document is defined as taking - references (such as "$ref") to an external Schema Resource and embedding the referenced - Schema Resources within the referring document. Bundling SHOULD be done in such a way that - all IRIs (used for referencing) in the base document and any referenced/embedded - documents do not require altering. - - - Each embedded JSON Schema Resource MUST identify itself with a IRI using the "$id" keyword, - and SHOULD make use of the "$schema" keyword to identify the dialect it is using, in the root of the - schema resource. It is RECOMMENDED that the IRI identifier value of "$id" be an Absolute IRI. - - - When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that - the Schema Resource be located as a value of a "$defs" object at the containing schema's root. - The key of the "$defs" for the now embedded Schema Resource MAY be the "$id" of the bundled schema - or some other form of application defined unique identifer (such as a UUID). This key is not - intended to be referenced in JSON Schema, but may be used by an application to aid the - bundling process. - - - A Schema Resource MAY be embedded in a location other than "$defs" where the location is defined - as a schema value. - - - A Bundled Schema Resource MUST NOT be bundled by replacing the schema object from which it was - referenced, or by wrapping the Schema Resource in other applicator keywords. - - - In order to produce identical output, references in the containing schema document to the - previously external Schema Resources MUST NOT be changed, and now resolve to a schema using the - "$id" of an embedded Schema Resource. Such identical output includes validation evaluation and IRIs - or paths used in resulting annotations or errors. - - - While the bundling process will often be the main method for creating a Compound Schema Document, - it is also possible and expected that some will be created by hand, potentially without individual - Schema Resources existing on their own previously. - -
-
- - When multiple schema resources are present in a single document, - schema resources which do not define with which dialect they should be processed - MUST be processed with the same dialect as the enclosing resource. - - - Since any schema that can be referenced can also be embedded, embedded schema resources MAY - specify different processing dialects using the "$schema" values from their enclosing resource. - -
-
- - Given that a Compound Schema Document may have embedded resources which identify as using different - dialects, these documents SHOULD NOT be validated by applying a meta-schema - to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate - validation process be provided in order to validate Schema Documents. Each Schema Resource - SHOULD be separately validated against its associated meta-schema. - - If you know a schema is what's being validated, you can identify if the schemas - is a Compound Schema Document or not, by way of use of "$id", which identifies an - embedded resource when used not at the document's root. - - - - A Compound Schema Document in which all embedded resources identify as using the same - dialect, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, - MAY be validated by applying the appropriate meta-schema. - -
-
- -
-
- - A schema MUST NOT be run into an infinite loop against an instance. For - example, if two schemas "#alice" and "#bob" both have an "allOf" property - that refers to the other, a naive validator might get stuck in an infinite - recursive loop trying to validate the instance. Schemas SHOULD NOT make - use of infinite recursive nesting like this; the behavior is undefined. - -
- -
- - Subschema objects (or booleans) are recognized by their use with known - applicator keywords or with location-reserving keywords such as - "$defs" that take one or more subschemas - as a value. These keywords may be "$defs" and the standard applicators - from this document, or extension keywords from a known vocabulary, or - implementation-specific custom keywords. - - - Multi-level structures of unknown keywords are capable of introducing - nested subschemas, which would be subject to the processing rules for - "$id". Therefore, having a reference target in such an unrecognized - structure cannot be reliably implemented, and the resulting behavior - is undefined. Similarly, a reference target under a known keyword, - for which the value is known not to be a schema, results in undefined - behavior in order to avoid burdening implementations with the need - to detect such targets. - - These scenarios are analogous to fetching a schema over HTTP - but receiving a response with a Content-Type other than - application/schema+json. An implementation can certainly - try to interpret it as a schema, but the origin server - offered no guarantee that it actually is any such thing. - Therefore, interpreting it as such has security implications - and may produce unpredictable results. - - - - Note that single-level custom keywords with identical syntax and - semantics to "$defs" do not allow for any intervening "$id" keywords, - and therefore will behave correctly under implementations that attempt - to use any reference target as a schema. However, this behavior is - implementation-specific and MUST NOT be relied upon for interoperability. - -
-
- -
- -
- - - JSON has been adopted widely by HTTP servers for automated APIs and robots. This - section describes how to enhance processing of JSON documents in a more RESTful - manner when used with protocols that support media types and - Web linking. - - -
- - It is RECOMMENDED that instances described by a schema provide a link to - a downloadable JSON Schema using the link relation "describedby", as defined by - Linked Data Protocol 1.0, section 8.1. - - - - In HTTP, such links can be attached to any response using the - Link header. An example of such a header would be: - - - ; rel="describedby" -]]> - -
- -
- - When used for hypermedia systems over a network, - HTTP is frequently the protocol of choice for - distributing schemas. Misbehaving clients can pose problems for server - maintainers if they pull a schema over the network more frequently than - necessary, when it's instead possible to cache a schema for a long period of - time. - - - HTTP servers SHOULD set long-lived caching headers on JSON Schemas. - HTTP clients SHOULD observe caching headers and not re-request documents within - their freshness period. - Distributed systems SHOULD make use of a shared cache and/or caching proxy. - - - Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema - implementation or software product. Since symbols are listed in decreasing order - of significance, the JSON Schema library name/version should precede the more - generic HTTP library name (if any). For example: - - - - Clients SHOULD be able to make requests with a "From" header so that server - operators can contact the owner of a potentially misbehaving script. - -
- -
- -
- -
- -
- - This section defines a vocabulary of applicator keywords that - are RECOMMENDED for use as the basis of other vocabularies. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/next/vocab/applicator>. - - - The current IRI for the corresponding meta-schema is: - . - -
- - Schema keywords typically operate independently, without - affecting each other's outcomes. - - - For schema author convenience, there are some exceptions among the - keywords in this vocabulary: - -
    -
  • - "additionalProperties", whose behavior is defined in terms of - "properties" and "patternProperties" -
    • -
  • - "items", whose behavior is defined in terms of "prefixItems" -
    • -
  • - "contains", whose behavior is affected by the presence and value of - "minContains" -
    • -
-
- -
- - These keywords apply subschemas to the same location in the instance - as the parent schema is being applied. They allow combining - or modifying the subschema results in various ways. - - - - Subschemas of these keywords evaluate the instance completely independently - such that the results of one such subschema MUST NOT impact the results of sibling - subschemas. Therefore subschemas may be applied in - any order. - - -
- - These keywords correspond to logical operators for combining or modifying - the boolean assertion results of the subschemas. They have no direct - impact on annotation collection, although they enable the same annotation - keyword to be applied to an instance location with different values. - Annotation keywords define their own rules for combining such values. - -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against all schemas defined by this keyword's value. - -
- -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against at least one schema defined by this keyword's value. - Note that when annotations are being collected, all subschemas MUST - be examined so that annotations are collected from each subschema - that validates successfully. - -
- -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against exactly one schema defined by this keyword's value. - -
- -
- - This keyword's value MUST be a valid JSON Schema. - - - An instance is valid against this keyword if it fails to validate - successfully against the schema defined by this keyword. - -
-
- -
- - Three of these keywords work together to implement conditional - application of a subschema based on the outcome of another subschema. - The fourth is a shortcut for a specific conditional case. - - - "if", "then", and "else" MUST NOT interact with each other across - subschema boundaries. In other words, an "if" in one - branch of an "allOf" MUST NOT have an impact on a "then" - or "else" in another branch. - - - There is no default behavior for "if", "then", or "else" - when they are not present. In particular, they MUST NOT - be treated as if present with an empty schema, and when - "if" is not present, both "then" and "else" MUST be - entirely ignored. - -
- - This keyword's value MUST be a valid JSON Schema. - - - This validation outcome of this keyword's subschema - has no direct effect on the overall validation - result. Rather, it controls which of the "then" - or "else" keywords are evaluated. - - - Instances that successfully validate against this - keyword's subschema MUST also be valid against - the subschema value of the "then" keyword, if - present. - - - Instances that fail to validate against this - keyword's subschema MUST also be valid against - the subschema value of the "else" keyword, if - present. - - - If annotations - are being collected, they are collected from this - keyword's subschema in the usual way, including when - the keyword is present without either "then" or "else". - -
-
- - This keyword's value MUST be a valid JSON Schema. - - - When "if" is present, and the instance successfully - validates against its subschema, then validation - succeeds against this keyword if the instance also - successfully validates against this keyword's subschema. - - - This keyword has no effect when "if" is absent, or - when the instance fails to validate against its - subschema. Implementations MUST NOT evaluate - the instance against this keyword, for either validation - or annotation collection purposes, in such cases. - -
-
- - This keyword's value MUST be a valid JSON Schema. - - - When "if" is present, and the instance fails to - validate against its subschema, then validation - succeeds against this keyword if the instance - successfully validates against this keyword's subschema. - - - This keyword has no effect when "if" is absent, or - when the instance successfully validates against its - subschema. Implementations MUST NOT evaluate - the instance against this keyword, for either validation - or annotation collection purposes, in such cases. - -
-
- - This keyword specifies subschemas that are evaluated if the instance - is an object and contains a certain property. - - - This keyword's value MUST be an object. - Each value in the object MUST be a valid JSON Schema. - - - If the object key is a property in the instance, the entire - instance must validate against the subschema. Its use is - dependent on the presence of the property. - - - Omitting this keyword has the same behavior as an empty object. - -
-
- - This keyword specifies subschemas that are evaluated if the instance is - an object and contains a certain property with a certain string value. - - - This keyword's value MUST be an object. Each value in the object MUST be - an object whose values MUST be valid JSON Schemas. - - - If the outer object key is a property in the instance and the inner - object key is equal to the value of that property, the entire instance - must validate against the schema. Its use is dependent on the presence - and value of the property. - - - Omitting this keyword has the same behavior as an empty object. - -
-
-
-
- - Each of these keywords defines a rule for applying its - subschema(s) to child instances, specifically object - properties and array items, and combining their results. - -
-
- - The value of "prefixItems" MUST be a non-empty array of valid JSON Schemas. - - - Validation succeeds if each element of the instance validates - against the subschema at the same position, if any. This keyword - does not constrain the length of the array. Only array positions - present in both the keyword's value and the instance value are - affected by this keyword. - - - This keyword produces an annotation value which is the largest - index to which this keyword applied a subschema. The value - MAY be a boolean true if a subschema was applied to every - index of the instance, such as is produced by the "items" keyword. - This annotation affects the behavior of "items" and "unevaluatedItems". - - - Omitting this keyword has the same assertion behavior as - an empty array. - -
- -
- - The value of "items" MUST be a valid JSON Schema. - - - This keyword applies its subschema to all instance elements - at indexes greater than the length of the "prefixItems" array - in the same schema object, as reported by the annotation result - of that "prefixItems" keyword. If no such annotation - result exists, "items" applies its subschema to all instance - array elements. - - Note that the behavior of "items" without "prefixItems" is - identical to that of the schema form of "items" in prior drafts. - When "prefixItems" is present, the behavior of "items" is - identical to the former "additionalItems" keyword. - - - - If the "items" subschema is applied to any - positions within the instance array, it produces an - annotation result of boolean true, indicating that all remaining array - elements have been evaluated against this keyword's subschema. - This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations MAY choose to implement or optimize this keyword - in another way that produces the same effect, such as by directly - checking for the presence and size of a "prefixItems" array. - Implementations that do not support annotation collection MUST do so. - -
-
- -
-
- - The value of "properties" MUST be an object. - Each value of this object MUST be a valid JSON Schema. - - - Validation succeeds if, for each name that appears in both - the instance and as a name within this keyword's value, the child - instance for that name successfully validates against the - corresponding schema. - - - The annotation result of this keyword is the set of instance - property names which are also present under this keyword. - This annotation affects the behavior of "additionalProperties" (in - this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty object. - -
- -
- - The value of "patternProperties" MUST be an object. Each property name - of this object SHOULD be a valid regular expression, according to the - ECMA-262 regular expression dialect. Each property value of this object - MUST be a valid JSON Schema. - - - Validation succeeds if, for each instance name that matches any - regular expressions that appear as a property name in this keyword's value, - the child instance for that name successfully validates against each - schema that corresponds to a matching regular expression. Recall: regular - expressions are not implicitly anchored. - - - The annotation result of this keyword is the set of instance - property names matched by at least one property under this keyword. - This annotation affects the behavior of "additionalProperties" (in this - vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary). - - - Omitting this keyword has the same assertion behavior as - an empty object. - -
- -
- - The value of "additionalProperties" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the presence and - annotation results of "properties" and "patternProperties" - within the same schema object. - Validation with "additionalProperties" applies only to the child - values of instance names that do not appear in the annotation - results of either "properties" or "patternProperties". - - - For all such properties, validation succeeds if the child instance - validates against the "additionalProperties" schema. - - - The annotation result of this keyword is the set of instance - property names validated by this keyword's subschema. - This annotation affects the behavior of "unevaluatedProperties" - in the Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations MAY choose to implement or optimize this keyword - in another way that produces the same effect, such as by directly - checking the names in "properties" and the patterns in - "patternProperties" against the instance property set. - Implementations that do not support annotation collection MUST do so. - - In defining this option, it seems there is the potential for - ambiguity in the output format. The ambiguity does not affect validation results, - but it does affect the resulting output format. - The ambiguity allows for multiple valid output results depending on whether annotations - are used or a solution that "produces the same effect" as draft-07. It is understood - that annotations from failing schemas are dropped. - See our - [Decision Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) - for further details. - - -
- -
- - The value of "propertyNames" MUST be a valid JSON Schema. - - - If the instance is an object, this keyword validates if every property name in - the instance validates against the provided schema. - Note the property name that the schema is testing will always be a string. - - - Omitting this keyword has the same behavior as an empty schema. - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - - This keyword modifies the behavior of "contains" within the same schema object, - as described below in the section for that keyword. - - - Validation MUST always succeed against this keyword. - The value of this keyword is used as its annotation result. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - This keyword modifies the behavior of "contains" within the same schema object, - as described below in the section for that keyword. - - - Validation MUST always succeed against this keyword. - The value of this keyword is used as its annotation result. - - Per , - omitted keywords MUST NOT produce annotation results. However, as described - in the section for "contains", the absence of this keyword's annotation - causes "contains" to assume a minimum value of 1. - -
- -
- - The value of this keyword MUST be a valid JSON Schema. - - - This keyword applies its subschema to array elements or object property values. - - - An instance is valid against "contains" if the number of elements or property - values that are valid against its subschema is with the inclusive range of - the minimum and (if any) maximum number of occurrences. - - - The maximum number of occurrences is provided by the "maxContains" keyword - within the same schema object as "contains". If "maxContains" is absent, - the maximum number of occurrences MUST be unbounded. - - - The minimum number of occurrences is provided by the "minContains" keyword - within the same schema object as "contains". If "minContains" is absent, - the minimum number of occurrences MUST be 1. - - - Implementations MAY implement the dependency on "minContians" and - "maxContains" by inspecting their values rather than reading annotations - produced by those keywords. - - - This keyword produces an annotation value which is an array of the - indexes or property names to which this keyword validates successfully - when applying its subschema, in ascending order. The value MAY be a - boolean "true" if the subschema validates successfully when applied to - every index or property value of the instance. The annotation MUST be - present if the instance array or object to which this keyword's schema - applies is empty. - - - This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary. - - - The subschema MUST be applied to every array element or object property - value even after the first match has been found, in order to collect - annotations for use by other keywords. This is to ensure that all possible - annotations are collected. - -
-
-
-
- -
- - The purpose of these keywords is to enable schema authors to apply - subschemas to array items or object properties that have not been - successfully evaluated against any dynamic-scope subschema of any - adjacent keywords. - - - These instance items or properties may have been unsuccessfully evaluated - against one or more adjacent keyword subschemas, such as when an assertion - in a branch of an "anyOf" fails. Such failed evaluations are not considered - to contribute to whether or not the item or property has been evaluated. - Only successful evaluations are considered. - - - If an item in an array or an object property is "successfully evaluated", it - is logically considered to be valid in terms of the representation of the - object or array that's expected. For example if a subschema represents a car, - which requires between 2-4 wheels, and the value of "wheels" is 6, the instance - object is not "evaluated" to be a car, and the "wheels" property is considered - "unevaluated (successfully as a known thing)", and does not retain any annotations. - - - Recall that adjacent keywords are keywords within the same schema object, - and that the dynamic-scope subschemas include reference targets as well as - lexical subschemas. - - - The behavior of these keywords depend on the annotation results of - adjacent keywords that apply to the instance location being validated. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Unevaluated Applicator - vocabulary, is: - <https://json-schema.org/draft/next/vocab/unevaluated>. - - - The current IRI for the corresponding meta-schema is: - . - - -
- - Schema keywords typically operate independently, without - affecting each other's outcomes. However, the keywords in this - vocabulary are notable exceptions: - -
    -
  • - "unevaluatedItems", whose behavior is defined in terms of annotations - from "prefixItems", "items", "contains", and itself -
    • -
  • - "unevaluatedProperties", whose behavior is defined in terms of - annotations from "properties", "patternProperties", - "additionalProperties", "contains", and itself -
    • -
-
- -
- - The value of "unevaluatedItems" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "prefixItems", "items", and "contains", - which can come from those keywords when they are adjacent to the - "unevaluatedItems" keyword. Those three annotations, as well as - "unevaluatedItems", can also result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - If no relevant annotations are present, the "unevaluatedItems" - subschema MUST be applied to all locations in the array. - If a boolean true value is present from any of the relevant annotations, - "unevaluatedItems" MUST be ignored. Otherwise, the subschema - MUST be applied to any index greater than the largest annotation - value for "prefixItems", which does not appear in any annotation - value for "contains". - - - This means that "prefixItems", "items", "contains", and all in-place - applicators MUST be evaluated before this keyword can be evaluated. - Authors of extension keywords MUST NOT define an in-place applicator - that would need to be evaluated after this keyword. - - - If the "unevaluatedItems" subschema is applied to any - positions within the instance array, it produces an - annotation result of boolean true, analogous to the - behavior of "items". - This annotation affects the behavior of "unevaluatedItems" in parent schemas. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - -
- -
- - The value of "unevaluatedProperties" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "properties", "patternProperties", - "contains", and "additionalProperties", which can come from those keywords when - they are adjacent to the "unevaluatedProperties" keyword. Those - four annotations, as well as "unevaluatedProperties", can also - result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - Validation with "unevaluatedProperties" applies only to the child - values of instance names that do not appear in the "properties", - "patternProperties", "additionalProperties", "contains", or - "unevaluatedProperties" annotation results that apply to the - instance location being validated. - - - For all such properties, validation succeeds if the child instance - validates against the "unevaluatedProperties" schema. - - - This means that "properties", "patternProperties", "additionalProperties", - "contains" and all in-place applicators MUST be evaluated before this keyword can - be evaluated. Authors of extension keywords MUST NOT define an in-place - applicator that would need to be evaluated after this keyword. - - - The annotation result of this keyword is the set of instance - property names validated by this keyword's subschema. - This annotation affects the behavior of "unevaluatedProperties" in parent schemas. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - -
-
- -
- - JSON Schema is defined to be platform-independent. As such, to increase compatibility - across platforms, implementations SHOULD conform to a standard validation output - format. This section describes the minimum requirements that consumers will need to - properly interpret validation results. - - -
- - JSON Schema output is defined using the JSON Schema data instance model as described - in section 4.2.1. Implementations MAY deviate from this as supported by their - specific languages and platforms, however it is RECOMMENDED that the output be - convertible to the JSON format defined herein via serialization or other means. - -
- -
- - This specification defines three output formats. See the "Output Structure" - section for the requirements of each format. - -
-
Flag
-
- A boolean which simply indicates the overall validation result - with no further details. -
-
List
-
- Provides validation information in a flat list structure. -
-
Hierarchical
-
- Provides validation information in a hierarchical - structure that follows the evaluation paths generated while processing - the schema. -
-
- - An implementation MUST provide the "flag" format and SHOULD provide at least one - of the "list" or "hierarchical" formats. Implementations SHOULD specify in - their documentation which formats they support. - - -
- -
- - Beyond the simplistic "flag" output, additional information is useful to aid in - debugging a schema or instance. Each sub-result SHOULD contain the information - contained within this section at a minimum. - - - A single object that contains all of these components is considered an - output unit. - - - Implementations MAY elect to provide additional information. - - -
- - The evaluation path to the schema object that produced the output unit. - The value MUST be expressed as a JSON Pointer, and it MUST include any - by-reference applicators such as "$ref" or "$dynamicRef". - - The schema may not actually have a value at the location indicated - by this pointer. It is provided as an indication of the traversal - path only. - - - - - Note that this pointer may not be resolvable by the normal JSON Pointer process - due to the inclusion of these by-reference applicator keywords. - - - The JSON key for this information is "evaluationPath". - -
- -
- - The absolute, dereferenced location of the schema object that produced - the output unit. The value MUST be expressed using the canonical IRI of the - relevant schema resource plus a JSON Pointer fragment that indicates the schema - object that produced the output. It MUST NOT include by-reference applicators - such as "$ref" or "$dynamicRef". - - Note that "absolute" here is in the sense of "absolute filesystem path" - (meaning the complete location) rather than the "absolute-IRI" - terminology from RFC 3987 (meaning with scheme and without fragment). - Schema locations will have a fragment in order to identify the specific - schema object. - - - - - - The JSON key for this information is "schemaLocation". - -
- -
- - The location of the JSON value within the instance being validated. The - value MUST be expressed as a JSON Pointer. - - - The JSON key for this information is "instanceLocation". - -
- -
- - Any errors produced by the validation. This property MUST NOT - be included if the validation was successful. The value - for this property MUST be an object where the keys are the names of - keywords and the values are the error message produced by the - associated keyword. - - - If the subschema itself is producing the error, that error MUST be - listed with an empty string key. - - Although there may be other cases where a subschema can produce - an error, the most common case is the "false" schema. In - cases like these, there is no keyword that produces the error, - so there is nothing to use as a key. Thus the empty string - is used instead. - - - - The specific wording for the message is not defined by this - specification. Implementations will need to provide this. - - - The JSON key for this information is "errors". - -
- -
- - Any annotations produced by the evaluation. This property MUST NOT - be included if the validation result of the containing subschema was - unsuccessful. - - - The value for this property MUST be an object where the - keys are the names of keywords and the values are the annotations - produced by the associated keyword. - - - Each keyword defines its own annotation data type (e.g. "properties" - produces a list of keywords, whereas "title" produces a string). - - - The JSON key for this information is "annotations". - -
- -
- - Any annotations produced and subsequently dropped by the evaluation - due to an unsuccessful validation result of the containing subschema. - This property MAY be included if the validation result of the containing - subschema was unsuccessful. It MUST NOT be included if the local - validation result of the containing subschema was successful. - - - Implementations that wish to provide these annotations MUST NOT provide - them as their default behavior. These annotations MUST only be included - by explicitly configuring the implementation to do so. - - - The value for this property MUST be an object where the - keys are the names of keywords and the values are the annotations - produced by the associated keyword. - - - Each keyword defines its own annotation data type (e.g. "properties" - produces a list of keywords, whereas "title" produces a string). - - - The JSON key for this information is "droppedAnnotations". - -
- -
- - Evaluation results generated by applying a subschema to the instance - or a child of the instance. - Keywords which have multiple subschemas (e.g. "anyOf") will generally - generate an output unit for each subschema. In order to accommodate - potentially multiple results, the value of this property MUST be an - array of output units, even if only a single output unit is produced. - - - For "list", this property will appear only at the root output unit - and will hold all output units in a flat list. - - - For "hierarchical", this property will contain results in a tree - structure where each output unit may itself have further nested results. - - - The sequence of output units within this list is not specified and - MAY be determined by the implementation. Sets of output units are - considered equivalent if they contain the same units, in any order. - - - The JSON key for these additional results is "details". - -
- -
- -
- - The output MUST be an object containing a boolean property named "valid". When - additional information about the result is required, the output MUST also contain - "details" as described below. - -
-
valid
-
a boolean value indicating the overall validation success or failure
- -
details
-
the collection of results produced by subschemas
-
- - For these examples, the following schema and instances will be used. - - - - The failing instance will produce the following errors: - -
    -
  • - The value at "/foo" - evaluated at "/properties/foo/allOf/0" - by following the path "/properties/foo/allOf/0" - by the "required" keyword - is missing the property "unspecified-prop". -
    • -
  • - The value at "/foo/foo-prop" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - by the "const" keyword - is not the constant value 1. -
    • -
  • - The value at "/bar/bar-prop" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - by the "type" keyword - is not a number. -
    • -
- - - "minimum" doesn't produce an error because it only operates on - instances that are numbers. - - - Note that the error message wording as depicted in the examples below is not a - requirement of this specification. Implementations SHOULD craft error messages - tailored for their audience or provide a templating mechanism that allows their - users to craft their own messages. - - - - The passing instance will produce the following annotations: - -
    -
  • - The keyword "title" - evaluated at "" - by following the path "" - will produce "root". -
    • -
  • - The keyword "properties" - evaluated at "" - by following the path "" - will produce ["foo", "bar"]. -
    • -
  • - The keyword "title" - evaluated at "/properties/foo" - by following the path "/properties/foo" - will produce "foo-title". -
    • -
  • - The keyword "properties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["foo-prop"]. -
    • -
  • - The keyword "additionalProperties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["unspecified-prop"]. -
    • -
  • - The keyword "title" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - will produce "foo-prop-title". -
    • -
  • - The keyword "title" - evaluated at "/$defs/bar" - by following the path "/properties/bar/$ref" - will produce "bar-title". -
    • -
  • - The keyword "properties" - evaluated at "/$defs/bar" - by following the path "/properties/var/$ref" - will produce ["bar-prop"]. -
    • -
  • - The keyword "title" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - will produce "bar-prop-title". -
    • -
- -
- - In the simplest case, merely the boolean result for the "valid" valid property - needs to be fulfilled. For this format, all other information is explicitly - omitted. - - - - Because no errors or annotations are returned with this format, it is - RECOMMENDED that implementations use short-circuiting logic to return - failure or success as soon as the outcome can be determined. For example, - if an "anyOf" keyword contains five subschemas, and the second one - passes, there is no need to check the other three. The logic can simply - return with success. - -
- -
- - The "List" structure is a flat list of output units contained within a - root output unit. - - - The root output unit contains "valid" for the overall result and "details" - for the list of specific results. All other information is explicitly - omitted from the root output unit. If the root schema produces errors or - annotations, then the output node for the root MUST be present within the - root output unit's "details" list with those errors or annotations. - - - Output units which do not contain errors or annotations SHOULD be excluded - from this format, however implementations MAY choose to include them for - completeness. - - -
- -
- - The "Hierarchical" structure is a tree structure that follows the - evaluation path during the validation process. Typically, it will - resemble the schema as if all referenced schemas were inlined in place - of their associated by-reference keywords. - - - All output units are included in this format. - - - The location properties of the root output unit MAY be omitted. - - - -
- -
- - For convenience, JSON Schema has been provided to validate output generated - by implementations. Its IRI is: - . - -
- -
- -
- -
- - Both schemas and instances are JSON values. As such, all security considerations - defined in RFC 8259 apply. - - - Instances and schemas are both frequently written by untrusted third parties, to be - deployed on public Internet servers. - Implementations should take care that the parsing and evaluating against schemas - does not consume excessive system resources. - Implementations MUST NOT fall into an infinite loop. - - - A malicious party could cause an implementation to repeatedly collect a copy - of a very large value as an annotation. Implementations SHOULD guard against - excessive consumption of system resources in such a scenario. - - - Servers MUST ensure that malicious parties cannot change the functionality of - existing schemas by uploading a schema with a pre-existing or very similar "$id". - - - Individual JSON Schema vocabularies are liable to also have their own security - considerations. Consult the respective specifications for more information. - - - Schema authors should take care with "$comment" contents, as a malicious - implementation can display them to end-users in violation of a spec, or - fail to strip them if such behavior is expected. - - - A malicious schema author could place executable code or other dangerous - material within a "$comment". Implementations MUST NOT parse or otherwise - take action based on "$comment" contents. - -
- -
-
- - The proposed MIME media type for JSON Schema is defined as follows: - -
-
Type name:
-
application
- -
Subtype name:
-
schema+json
- -
Required parameters:
-
N/A
- -
Encoding considerations:
-
- Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. -
- -
Security considerations:
-
See above.
- -
Interoperability considerations:
-
- See Sections - , - , and - above. -
- -
Fragment identifier considerations:
-
- See -
-
-
-
- - The proposed MIME media type for JSON Schema Instances that require - a JSON Schema-specific media type is defined as follows: - -
-
Type name:
-
application
- -
Subtype name:
-
schema-instance+json
- -
Required parameters:
-
N/A
- -
Encoding considerations:
-
- Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. -
- -
Security considerations:
-
See above.
- -
Interoperability considerations:
-
- See Sections - , - , and - above. -
- -
Fragment identifier considerations:
-
See
-
-
-
- - - - - - &RFC2119; - &RFC3986; - &RFC3987; - &RFC6839; - &RFC6901; - &RFC8259; - &ldp; - - - ECMA-262, 11th edition specification - - - - - - - - &RFC6596; - &RFC7049; - &RFC7231; - &RFC8288; - &fragid-best-practices; - &xptr-framework; - - - JSON Schema Validation: A Vocabulary for Structural Validation of JSON - - - - - - - - - - - - - - - - JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON - - - - - - - - - - - - - Namespaces in XML 1.1 (Second Edition) - - Textuality -
- tbray@textuality.com -
- - - Contivo, Inc. -
- dmh@contivo.com -
- - - Microsoft -
- andrewl@microsoft.com -
- - - University of Edinburgh and Markup Technology Ltd -
- richard@cogsci.ed.ac.uk -
- - - - - - -
- - Consider the following schema, which shows "$id" being used to identify - both the root schema and various subschemas, and "$anchor" being used - to define plain name fragment identifiers. - - - - The schemas at the following IRI-encoded JSON - Pointers (relative to the root schema) have the following - base IRIs, and are identifiable by any listed IRI in accordance with - and above. - -
-
# (document root)
-
-
-
canonical (and base) IRI"
-
https://example.com/root.json
- -
canonical resource IRI plus pointer fragment"
-
https://example.com/root.json#
-
-
- -
#/$defs/A
-
-
-
base IRI
-
https://example.com/root.json
- -
canonical resource IRI plus plain fragment
-
https://example.com/root.json#foo
- -
canonical resource IRI plus pointer fragment
-
https://example.com/root.json#/$defs/A
-
-
- -
#/$defs/B
-
-
-
canonical (and base) IRI
-
https://example.com/other.json
- -
canonical resource IRI plus pointer fragment
-
https://example.com/other.json#
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B
-
-
- -
#/$defs/B/$defs/X
-
-
-
base IRI
-
https://example.com/other.json
- -
canonical resource IRI plus plain fragment
-
https://example.com/other.json#bar
- -
canonical resource IRI plus pointer fragment
-
https://example.com/other.json#/$defs/X
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B/$defs/X
-
-
- -
#/$defs/B/$defs/Y
-
-
-
canonical (and base) IRI
-
https://example.com/t/inner.json
- -
canonical IRI plus plain fragment
-
https://example.com/t/inner.json#bar
- -
canonical IRI plus pointer fragment
-
https://example.com/t/inner.json#
- -
base IRI of enclosing (other.json) resource plus fragment
-
https://example.com/other.json#/$defs/Y
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B/$defs/Y
-
-
- -
#/$defs/C
-
-
-
canonical (and base) IRI
-
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f
- -
canonical IRI plus pointer fragment
-
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/C
-
-
-
- - Note: The fragment part of the IRI does not make it canonical or non-canonical, - rather, the base IRI used (as part of the full IRI with any fragment) is what - determines the canonical nature of the resulting full IRI. - - Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, and - direct you to read the CREF located in the - JSON Pointer fragments and embedded schema resources - section for futher comments. - - - -
- -
- - Various tools have been created to rearrange schema documents - based on how and where references ("$ref") appear. This appendix discusses - which use cases and actions are compliant with this specification. - -
- - A set of schema resources intended for use together can be organized - with each in its own schema document, all in the same schema document, - or any granularity of document grouping in between. - - - Numerous tools exist to perform various sorts of reference removal. - A common case of this is producing a single file where all references - can be resolved within that file. This is typically done to simplify - distribution, or to simplify coding so that various invocations - of JSON Schema libraries do not have to keep track of and load - a large number of resources. - - - This transformation can be safely and reversibly done as long as - all static references (e.g. "$ref") use IRI-references that resolve - to IRIs using the canonical resource IRI as the base, and all schema - resources have an absolute-IRI as the "$id" in their root schema. - - - With these conditions met, each external resource can be copied - under "$defs", without breaking any references among the resources' - schema objects, and without changing any aspect of validation or - annotation results. The names of the schemas under "$defs" do - not affect behavior, assuming they are each unique, as they - do not appear in the canonical IRIs for the embedded resources. - -
-
- - Attempting to remove all references and produce a single schema document does not, - in all cases, produce a schema with identical behavior to the original form. - - - Since "$ref" is now treated like any other keyword, with other keywords allowed - in the same schema objects, fully supporting non-recursive "$ref" removal in - all cases can require relatively complex schema manipulations. It is beyond - the scope of this specification to determine or provide a set of safe "$ref" - removal transformations, as they depend not only on the schema structure - but also on the intended usage. - -
-
- -
- - Consider the following two schemas describing a simple - recursive tree structure, where each node in the tree - can have a "data" field of any type. The first schema - allows and ignores other instance properties. The second is - more strict and only allows the "data" and "children" properties. - An example instance with "data" misspelled as "daat" is also shown. - - - - When we load these two schemas, we will notice the "$dynamicAnchor" - named "node" (note the lack of "#" as this is just the name) - present in each, resulting in the following full schema IRIs: -
    -
  • "https://example.com/tree#node"
    • -
  • "https://example.com/strict-tree#node"
    • -
- In addition, JSON Schema implementations keep track of the fact - that these fragments were created with "$dynamicAnchor". - - - If we apply the "strict-tree" schema to the instance, we will follow - the "$ref" to the "tree" schema, examine its "children" subschema, - and find the "$dynamicRef": to "#node" (note the "#" for IRI fragment syntax) - in its "items" subschema. That reference resolves to - "https://example.com/tree#node", which is a IRI with a fragment - created by "$dynamicAnchor". Therefore we must examine the dynamic - scope before following the reference. - - - At this point, the evaluation path is - "#/$ref/properties/children/items/$dynamicRef", with a dynamic scope - containing (from the outermost scope to the innermost): -
    -
  1. "https://example.com/strict-tree#"
    2. -
  2. "https://example.com/tree#"
    3. -
  3. "https://example.com/tree#/properties/children"
    4. -
  4. "https://example.com/tree#/properties/children/items"
    5. -
- - - Since we are looking for a plain name fragment, which can be - defined anywhere within a schema resource, the JSON Pointer fragments - are irrelevant to this check. That means that we can remove those - fragments and eliminate consecutive duplicates, producing: -
    -
  1. "https://example.com/strict-tree"
    2. -
  2. "https://example.com/tree"
    3. -
- - - In this case, the outermost resource also has a "node" fragment - defined by "$dynamicAnchor". Therefore instead of resolving the - "$dynamicRef" to "https://example.com/tree#node", we resolve it to - "https://example.com/strict-tree#node". - - - This way, the recursion in the "tree" schema recurses to the root - of "strict-tree", instead of only applying "strict-tree" to the - instance root, but applying "tree" to instance children. - - - This example shows both "$dynamicAnchor"s in the same place - in each schema, specifically the resource root schema. - Since plain-name fragments are independent of the JSON structure, - this would work just as well if one or both of the node schema objects - were moved under "$defs". It is the matching "$dynamicAnchor" values - which tell us how to resolve the dynamic reference, not any sort of - correlation in JSON structure. - -
- -
-
- - Vocabulary authors should - take care to avoid keyword name collisions if the vocabulary is intended - for broad use, and potentially combined with other vocabularies. JSON - Schema does not provide any formal namespacing system, but also does - not constrain keyword names, allowing for any number of namespacing - approaches. - - - Vocabularies may build on each other, such as by defining the behavior - of their keywords with respect to the behavior of keywords from another - vocabulary, or by using a keyword from another vocabulary with - a restricted or expanded set of acceptable values. Not all such - vocabulary re-use will result in a new vocabulary that is compatible - with the vocabulary on which it is built. Vocabulary authors should - clearly document what level of compatibility, if any, is expected. - - - Meta-schema authors should not use "$vocabulary" to combine multiple - vocabularies that define conflicting syntax or semantics for the same - keyword. As semantic conflicts are not generally detectable through - schema validation, implementations are not expected to detect such - conflicts. If conflicting vocabularies are declared, the resulting - behavior is undefined. - - - Vocabulary authors SHOULD provide a meta-schema that validates the - expected usage of the vocabulary's keywords on their own. Such meta-schemas - SHOULD not forbid additional keywords, and MUST not forbid any - keywords from the Core vocabulary. - - - It is recommended that meta-schema authors reference each vocabulary's - meta-schema using the "allOf" keyword, - although other mechanisms for constructing the meta-schema may be - appropriate for certain use cases. - - - The recursive nature of meta-schemas makes the "$dynamicAnchor" - and "$dynamicRef" keywords particularly useful for extending - existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema - which extends the Validation meta-schema. - - - Meta-schemas may impose additional constraints, including describing - keywords not present in any vocabulary, beyond what the meta-schemas - associated with the declared vocabularies describe. This allows for - restricting usage to a subset of a vocabulary, and for validating - locally defined keywords not intended for re-use. - - - However, meta-schemas should not contradict any vocabularies that - they declare, such as by requiring a different JSON type than - the vocabulary expects. The resulting behavior is undefined. - - - Meta-schemas intended for local use, with no need to test for - vocabulary support in arbitrary implementations, can safely omit - "$vocabulary" entirely. - -
- -
- - This meta-schema explicitly declares both the Core and Applicator vocabularies, - together with an extension vocabulary, and combines their meta-schemas with - an "allOf". The extension vocabulary's meta-schema, which describes only the - keywords in that vocabulary, is shown after the main example meta-schema. - - - The main example meta-schema also restricts the usage of the Unevaluated - vocabulary by forbidding the keywords prefixed with "unevaluated", which - are particularly complex to implement. This does not change the semantics - or set of keywords defined by the other vocabularies. It just ensures - that schemas using this meta-schema that attempt to use the keywords - prefixed with "unevaluated" will fail validation against this meta-schema. - - - Finally, this meta-schema describes the syntax of a keyword, "localKeyword", - that is not part of any vocabulary. Presumably, the implementors and users - of this meta-schema will understand the semantics of "localKeyword". - JSON Schema does not define any mechanism for expressing keyword semantics - outside of vocabularies, making them unsuitable for use except in a - specific environment in which they are understood. - - - This meta-schema combines several vocabularies for general use. - - - - This meta-schema describes only a single extension vocabulary. - - - - As shown above, even though each of the single-vocabulary meta-schemas - referenced in the general-use meta-schema's "allOf" declares its - corresponding vocabulary, this new meta-schema must re-declare them. - - - The standard meta-schemas that combine all vocabularies defined by - the Core and Validation specification, and that combine all vocabularies - defined by those specifications as well as the Hyper-Schema specification, - demonstrate additional complex combinations. These IRIs for these - meta-schemas may be found in the Validation and Hyper-Schema specifications, - respectively. - - - While the general-use meta-schema can validate the syntax of "minDate", - it is the vocabulary that defines the logic behind the semantic meaning - of "minDate". Without an understanding of the semantics (in this example, - that the instance value must be a date equal to or after the date - provided as the keyword's value in the schema), an implementation can - only validate the syntactic usage. In this case, that means validating - that it is a date-formatted string (using "pattern" to ensure that it is - validated even when "format" functions purely as an annotation, as explained - in the Validation specification. - -
-
- -
- - While the presence of references is expected to be transparent - to validation results, generative use cases such as code generators - and UI renderers often consider references to be semantically significant. - - - To make such use case-specific semantics explicit, the best practice - is to create an annotation keyword for use in the same - schema object alongside of a reference keyword such as "$ref". - - - For example, here is a hypothetical keyword for determining - whether a code generator should consider the reference - target to be a distinct class, and how those classes are related. - Note that this example is solely for illustrative purposes, and is - not intended to propose a functional code generation keyword. - - - - Here, this schema represents some sort of object-oriented class. - The first reference in the "allOf" is noted as the base class. - The second is not assigned a class relationship, meaning that the - code generator should combine the target's definition with this - one as if no reference were involved. - - - Looking at the properties, "foo" is flagged as object composition, - while the "date" property is not. It is simply a field with - sub-fields, rather than an instance of a distinct class. - - - This style of usage requires the annotation to be in the same object - as the reference, which must be recognizable as a reference. - -
- -
- - Thanks to - Gary Court, - Francis Galiegue, - Kris Zyp, - Geraint Luff, - and Henry Andrews - for their work on the initial drafts of JSON Schema. - - - Thanks to - Jason Desrosiers, - Daniel Perrett, - Erik Wilde, - Evgeny Poberezkin, - Brad Bowman, - Gowry Sankar, - Donald Pipowitch, - Dave Finlay, - Denis Laxalde, - Phil Sturgeon, - Shawn Silverman, - and Karen Etheridge - for their submissions and patches to the document. - -
- -
- - This section to be removed before leaving Internet-Draft status. - - -
-
    -
  • "contains" now applies to objects as well as arrays
    • -
  • Use IRIs instead of URIs
    • -
  • Remove bookending requirement for "$dynamicRef"
    • -
  • Add "propertyDependencies" keyword
    • -
-
- -
-
    -
  • Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations
    • -
  • Clarify various aspects of "canonical URIs"
    • -
  • Comment on ambiguity around annotations and "additionalProperties"
    • -
  • Clarify Vocabularies need not be formally defined
    • -
  • Remove references to remaining media-type parameters
    • -
  • Fix multiple examples
    • -
-
- -
-
    -
  • "$schema" MAY change for embedded resources
    • -
  • Array-value "items" functionality is now "prefixItems"
    • -
  • "items" subsumes the old function of "additionalItems"
    • -
  • "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified
    • -
  • Rename $recursive* to $dynamic*, with behavior modification
    • -
  • $dynamicAnchor defines a fragment like $anchor
    • -
  • $dynamic* (previously $recursive) no longer use runtime base URI determination
    • -
  • Define Compound Schema Documents (bundle) and processing
    • -
  • Reference ECMA-262, 11th edition for regular expression support
    • -
  • Regular expression should support unicode
    • -
  • Remove media type parameters
    • -
  • Specify Unknown keywords are collected as annotations
    • -
  • Moved "unevaluatedItems" and "unevaluatedProperties" from core into their own vocabulary
    • -
-
- -
-
    -
  • Update to RFC 8259 for JSON specification
    • -
  • Moved "definitions" from the Validation specification here as "$defs"
    • -
  • Moved applicator keywords from the Validation specification as their own vocabulary
    • -
  • Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas"
    • -
  • Formalized annotation collection
    • -
  • Specified recommended output formats
    • -
  • Defined keyword interactions in terms of annotation and assertion results
    • -
  • Added "unevaluatedProperties" and "unevaluatedItems"
    • -
  • Define "$ref" behavior in terms of the assertion, applicator, and annotation model
    • -
  • Allow keywords adjacent to "$ref"
    • -
  • Note undefined behavior for "$ref" targets involving unknown keywords
    • -
  • Add recursive referencing, primarily for meta-schema extension
    • -
  • Add the concept of formal vocabularies, and how they can be recognized through meta-schemas
    • -
  • Additional guidance on initial base URIs beyond network retrieval
    • -
  • Allow "schema" media type parameter for "application/schema+json"
    • -
  • Better explanation of media type parameters and the HTTP Accept header
    • -
  • Use "$id" to establish canonical and base absolute-URIs only, no fragments
    • -
  • Replace plain-name-fragment-only form of "$id" with "$anchor"
    • -
  • Clarified that the behavior of JSON Pointers across "$id" boundary is unreliable
    • -
-
- -
-
    -
  • This draft is purely a clarification with no functional changes
    • -
  • Emphasized annotations as a primary usage of JSON Schema
    • -
  • Clarified $id by use cases
    • -
  • Exhaustive schema identification examples
    • -
  • Replaced "external referencing" with how and when an implementation might know of a schema from another document
    • -
  • Replaced "internal referencing" with how an implementation should recognized schema identifiers during parsing
    • -
  • Dereferencing the former "internal" or "external" references is always the same process
    • -
  • Minor formatting improvements
    • -
-
- -
-
    -
  • Make the concept of a schema keyword vocabulary more clear
    • -
  • Note that the concept of "integer" is from a vocabulary, not the data model
    • -
  • Classify keywords as assertions or annotations and describe their general behavior
    • -
  • Explain the boolean schemas in terms of generalized assertions
    • -
  • Reserve "$comment" for non-user-visible notes about the schema
    • -
  • Wording improvements around "$id" and fragments
    • -
  • Note the challenges of extending meta-schemas with recursive references
    • -
  • Add "application/schema-instance+json" media type
    • -
  • Recommend a "schema" link relation / parameter instead of "profile"
    • -
-
- -
-
    -
  • Updated intro
    • -
  • Allowed for any schema to be a boolean
    • -
  • "$schema" SHOULD NOT appear in subschemas, although that may change
    • -
  • Changed "id" to "$id"; all core keywords prefixed with "$"
    • -
  • Clarify and formalize fragments for application/schema+json
    • -
  • Note applicability to formats such as CBOR that can be represented in the JSON data model
    • -
-
- -
-
    -
  • Updated references to JSON
    • -
  • Updated references to HTTP
    • -
  • Updated references to JSON Pointer
    • -
  • Behavior for "id" is now specified in terms of RFC3986
    • -
  • Aligned vocabulary usage for URIs with RFC3986
    • -
  • Removed reference to draft-pbryan-zyp-json-ref-03
    • -
  • Limited use of "$ref" to wherever a schema is expected
    • -
  • Added definition of the "JSON Schema data model"
    • -
  • Added additional security considerations
    • -
  • Defined use of subschema identifiers for "id"
    • -
  • Rewrote section on usage with HTTP
    • -
  • Rewrote section on usage with rel="describedBy" and rel="profile"
    • -
  • Fixed numerous invalid examples
    • -
-
- -
-
    -
  • Salvaged from draft v3.
    • -
  • Split validation keywords into separate document.
    • -
  • Split hypermedia keywords into separate document.
    • -
  • Initial post-split draft.
    • -
  • Mandate the use of JSON Reference, JSON Pointer.
    • -
  • Define the role of "id". Define URI resolution scope.
    • -
  • Add interoperability considerations.
    • -
-
- -
-
    -
  • Initial draft.
    • -
-
-
- - diff --git a/jsonschema-validation.md b/jsonschema-validation.md new file mode 100644 index 00000000..8feb266f --- /dev/null +++ b/jsonschema-validation.md @@ -0,0 +1,1114 @@ +# JSON Schema Validation: A Vocabulary for Structural Validation of JSON + +## Abstract + +JSON Schema (application/schema+json) has several purposes, one of which is JSON +instance validation. This document specifies a vocabulary for JSON Schema to +describe the meaning of JSON documents, provide hints for user interfaces +working with JSON data, and to make assertions about what a valid document must +look like. + +## Note to Readers + +The issues list for this draft can be found at +. + +For additional information, see . + +To provide feedback, use this issue tracker, the communication methods listed on +the homepage, or email the document editors. + +## Table of Contents + +## Introduction + +JSON Schema can be used to require that a given JSON document (an instance) +satisfies a certain number of criteria. These criteria are asserted by using +keywords described in this specification. In addition, a set of keywords is also +defined to assist in interactive user interface instance generation. + +This specification will use the concepts, syntax, and terminology defined by the +[JSON Schema core](#json-schema) specification. + +## Conventions and Terminology +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119](#rfc2119). + +This specification uses the term "container instance" to refer to both array and +object instances. It uses the term "children instances" to refer to array +elements or object member values. + +Elements in an array value are said to be unique if no two elements of this +array are [equal](#json-schema). + +## Overview + +JSON Schema validation asserts constraints on the structure of instance data. +An instance location that satisfies all asserted constraints is then annotated +with any keywords that contain non-assertion information, such as descriptive +metadata and usage hints. If all locations within the instance satisfy all +asserted constraints, then the instance is said to be valid against the schema. + +Each schema object is independently evaluated against each instance location to +which it applies. This greatly simplifies the implementation requirements for +validators by ensuring that they do not need to maintain state across the +document-wide validation process. + +This specification defines a set of assertion keywords, as well as a small +vocabulary of metadata keywords that can be used to annotate the JSON instance +with useful information. The {{format}} keyword is intended primarily as an +annotation, but can optionally be used as an assertion. The {{content}} keywords +are annotations for working with documents embedded as JSON strings. + +## Interoperability Considerations + +### Validation of String Instances + +It should be noted that the nul character (\u0000) is valid in a JSON string. An +instance to validate may contain a string value with this character, regardless +of the ability of the underlying programming language to deal with such data. + +### Validation of Numeric Instances + +The JSON specification allows numbers with arbitrary precision, and JSON Schema +does not add any such bounds. This means that numeric instances processed by +JSON Schema can be arbitrarily large and/or have an arbitrarily long decimal +part, regardless of the ability of the underlying programming language to deal +with such data. + +### Regular Expressions {#regexinterop} + +Keywords that use regular expressions, or constrain the instance value to be a +regular expression, are subject to the interoperability considerations for +regular expressions in the [JSON Schema Core](#json-schema) specification. + +## Meta-Schema {#meta-schema} + +The current IRI for the default JSON Schema dialect meta-schema is +`https://json-schema.org/draft/next/schema`. For schema author convenience, this +meta-schema describes a dialect consisting of all vocabularies defined in this +specification and the JSON Schema Core specification, as well as two former +keywords which are reserved for a transitional period. Individual vocabulary and +vocabulary meta-schema IRIs are given for each section below. Certain +vocabularies are optional to support, which is explained in detail in the +relevant sections. + +Updated vocabulary and meta-schema IRIs MAY be published between specification +drafts in order to correct errors. Implementations SHOULD consider IRIs dated +after this specification draft and before the next to indicate the same syntax +and semantics as those listed here. + +## A Vocabulary for Structural Validation + +Validation keywords in a schema impose requirements for successful validation of +an instance. These keywords are all assertions without any annotation behavior. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Validation vocabulary, is: +`https://json-schema.org/draft/next/vocab/validation`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/validation`. + +### Validation Keywords for Any Instance Type {#general} + +#### `type` + +The value of this keyword MUST be either a string or an array. If it is an +array, elements of the array MUST be strings and MUST be unique. + +String values MUST be one of the six primitive types ("null", "boolean", +"object", "array", "number", or "string"), or "integer" which matches any number +with a zero fractional part. + +If the value of `type` is a string, then an instance validates successfully if +its type matches the type represented by the value of the string. + +If the value of `type` is an array, then an instance validates successfully if +its type matches any of the types indicated by the strings in the array. + +#### `enum` {#enum} + +The value of this keyword MUST be an array. This array SHOULD have at least one +element. Elements in the array SHOULD be unique. + +An instance validates successfully against this keyword if its value is equal to +one of the elements in this keyword's array value. + +Elements in the array might be of any type, including null. + +#### `const` + +The value of this keyword MAY be of any type, including null. + +Use of this keyword is functionally equivalent to an [`enum`](#enum) with a +single value. + +An instance validates successfully against this keyword if its value is equal to +the value of the keyword. + +### Validation Keywords for Numeric Instances (number and integer) {#numeric} + +#### `multipleOf` + +The value of `multipleOf` MUST be a number, strictly greater than 0. + +A numeric instance is valid only if division by this keyword's value results in +an integer. + +#### `maximum` + +The value of `maximum` MUST be a number, representing an inclusive upper limit +for a numeric instance. + +If the instance is a number, then this keyword validates only if the instance is +less than or exactly equal to `maximum`. + +#### `exclusiveMaximum` + +The value of `exclusiveMaximum` MUST be a number, representing an exclusive +upper limit for a numeric instance. + +If the instance is a number, then the instance is valid only if it has a value +strictly less than (not equal to) `exclusiveMaximum`. + +#### `minimum` + +The value of `minimum` MUST be a number, representing an inclusive lower limit +for a numeric instance. + +If the instance is a number, then this keyword validates only if the instance is +greater than or exactly equal to `minimum`. + +#### `exclusiveMinimum` + +The value of `exclusiveMinimum` MUST be a number, representing an exclusive +lower limit for a numeric instance. + +If the instance is a number, then the instance is valid only if it has a value +strictly greater than (not equal to) `exclusiveMinimum`. + +### Validation Keywords for Strings {#string} + +#### `maxLength` + +The value of this keyword MUST be a non-negative integer. + +A string instance is valid against this keyword if its length is less than, or +equal to, the value of this keyword. + +The length of a string instance is defined as the number of its characters as +defined by [RFC 8259](#rfc8259). + +#### `minLength` + +The value of this keyword MUST be a non-negative integer. + +A string instance is valid against this keyword if its length is greater than, +or equal to, the value of this keyword. + +The length of a string instance is defined as the number of its characters as +defined by [RFC 8259](#rfc8259). + +Omitting this keyword has the same behavior as a value of 0. + +#### `pattern` {#pattern} + +The value of this keyword MUST be a string. This string SHOULD be a valid +regular expression, according to the ECMA-262 regular expression dialect. + +A string instance is considered valid if the regular expression matches the +instance successfully. Recall: regular expressions are not implicitly anchored. + +### Validation Keywords for Arrays + +#### `maxItems` + +The value of this keyword MUST be a non-negative integer. + +An array instance is valid against `maxItems` if its size is less than, or equal +to, the value of this keyword. + +#### `minItems` + +The value of this keyword MUST be a non-negative integer. + +An array instance is valid against `minItems` if its size is greater than, or +equal to, the value of this keyword. + +Omitting this keyword has the same behavior as a value of 0. + +#### `uniqueItems` + +The value of this keyword MUST be a boolean. + +If this keyword has boolean value false, the instance validates successfully. If +it has boolean value true, the instance validates successfully if all of its +elements are unique. + +Omitting this keyword has the same behavior as a value of false. + +### Validation Keywords for Objects + +#### `maxProperties` + +The value of this keyword MUST be a non-negative integer. + +An object instance is valid against `maxProperties` if its number of properties +is less than, or equal to, the value of this keyword. + +#### `minProperties` + +The value of this keyword MUST be a non-negative integer. + +An object instance is valid against `minProperties` if its number of properties +is greater than, or equal to, the value of this keyword. + +Omitting this keyword has the same behavior as a value of 0. + +#### `required` + +The value of this keyword MUST be an array. Elements of this array, if any, MUST +be strings, and MUST be unique. + +An object instance is valid against this keyword if every item in the array is +the name of a property in the instance. + +Omitting this keyword has the same behavior as an empty array. + +#### `dependentRequired` + +The value of this keyword MUST be an object. Properties in this object, if any, +MUST be arrays. Elements in each array, if any, MUST be strings, and MUST be +unique. + +This keyword specifies properties that are required if a specific other property +is present. Their requirement is dependent on the presence of the other +property. + +Validation succeeds if, for each name that appears in both the instance and as a +name within this keyword's value, every item in the corresponding array is also +the name of a property in the instance. + +Omitting this keyword has the same behavior as an empty object. + +## Vocabularies for Semantic Content With `format` {#format} + +### Foreword + +Structural validation alone may be insufficient to allow an application to +correctly utilize certain values. The `format` annotation keyword is defined to +allow schema authors to convey semantic information for a fixed subset of values +which are accurately described by authoritative resources, be they RFCs or other +external specifications. + +The value of this keyword is called a format attribute. It MUST be a string. A +format attribute can generally only validate a given set of instance types. If +the type of the instance to validate is not in this set, validation for this +format attribute and instance SHOULD succeed. All format attributes defined in +this section apply to strings, but a format attribute can be specified to apply +to any instance types defined in the data model defined in the [core JSON +Schema.](#json-schema)[^1] + +[^1]: Note that the `type` keyword in this specification defines an "integer" +type which is not part of the data model. Therefore a format attribute can be +limited to numbers, but not specifically to integers. However, a numeric format +can be used alongside the `type` keyword with a value of "integer", or could be +explicitly defined to always pass if the number is not an integer, which +produces essentially the same behavior as only applying to integers. + +The current IRI for this vocabulary, known as the Format-Annotation vocabulary, +is: `https://json-schema.org/draft/next/vocab/format-annotation`. The current +IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/format-annotation`. Implementing +support for this vocabulary is REQUIRED. + +In addition to the Format-Annotation vocabulary, a secondary vocabulary is +available for custom meta-schemas that defines `format` as an assertion. The IRI +for the Format-Assertion vocabulary, is: +`https://json-schema.org/draft/next/vocab/format-assertion`. The current IRI for +the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/format-assertion`. Implementing support +for the Format-Assertion vocabulary is OPTIONAL. + +Specifying both the Format-Annotation and the Format-Assertion vocabularies is +functionally equivalent to specifying only the Format-Assertion vocabulary since +its requirements are a superset of the Format-Annotation vocabulary. + +### Implementation Requirements + +The `format` keyword functions as defined by the vocabulary which is referenced. + +#### Format-Annotation Vocabulary + +The value of format MUST be collected as an annotation, if the implementation +supports annotation collection. This enables application-level validation when +schema validation is unavailable or inadequate. + +Implementations MAY still treat `format` as an assertion in addition to an +annotation and attempt to validate the value's conformance to the specified +semantics. The implementation MUST provide options to enable and disable such +evaluation and MUST be disabled by default. Implementations SHOULD document +their level of support for such validation.[^2] + +[^2]: Specifying the Format-Annotation vocabulary and enabling validation in an +implementation should not be viewed as being equivalent to specifying the +Format-Assertion vocabulary since implementations are not required to provide +full validation support when the Format-Assertion vocabulary is not specified. + +When the implementation is configured for assertion behavior, it: + +- SHOULD provide an implementation-specific best effort validation for each + format attribute defined below; +- MAY choose to implement validation of any or all format attributes as a no-op + by always producing a validation result of true;[^3] + +[^3]: This matches the current reality of implementations, which provide widely +varying levels of validation, including no validation at all, for some or all +format attributes. It is also designed to encourage relying only on the +annotation behavior and performing semantic validation in the application, which +is the recommended best practice. + +#### Format-Assertion Vocabulary + +When the Format-Assertion vocabulary is declared with a value of true, +implementations MUST provide full validation support for all of the formats +defined by this specificaion. Implementations that cannot provide full +validation support MUST refuse to process the schema. + +An implementation that supports the Format-Assertion vocabulary: + +- MUST still collect `format` as an annotation if the implementation supports + annotation collection; +- MUST evaluate `format` as an assertion; +- MUST implement syntactic validation for all format attributes defined in this + specification, and for any additional format attributes that it recognizes, + such that there exist possible instance values of the correct type that will + fail validation. + +The requirement for minimal validation of format attributes is +intentionally vague and permissive, due to the complexity involved in many of +the attributes. Note in particular that the requirement is limited to syntactic +checking; it is not to be expected that an implementation would send an email, +attempt to connect to a URL, or otherwise check the existence of an entity +identified by a format instance.[^4] + +[^4]: The expectation is that for simple formats such as date-time, syntactic +validation will be thorough. For a complex format such as email addresses, which +are the amalgamation of various standards and numerous adjustments over time, +with obscure and/or obsolete rules that may or may not be restricted by other +applications making use of the value, a minimal validation is sufficient. For +example, an instance string that does not contain an "@" is clearly not a valid +email address, and an "email" or "hostname" containing characters outside of +7-bit ASCII is likewise clearly invalid. + +It is RECOMMENDED that implementations use a common parsing library for each +format, or a well-known regular expression. Implementations SHOULD clearly +document how and to what degree each format attribute is validated. + +The [standard core and validation meta-schema](#meta-schema) includes this +vocabulary in its `$vocabulary` keyword with a value of false, since by default +implementations are not required to support this keyword as an assertion. +Supporting the format vocabulary with a value of true is understood to greatly +increase code size and in some cases execution time, and will not be appropriate +for all implementations. + +#### Custom format attributes + +Implementations MAY support custom format attributes. Save for agreement between +parties, schema authors SHALL NOT expect a peer implementation to support such +custom format attributes. An implementation MUST NOT fail to collect unknown +formats as annotations. When the Format-Assertion vocabulary is specified, +implementations MUST fail upon encountering unknown formats. + +Vocabularies do not support specifically declaring different value sets for +keywords. Due to this limitation, and the historically uneven implementation of +this keyword, it is RECOMMENDED to define additional keywords in a custom +vocabulary rather than additional format attributes if interoperability is +desired. + +### Defined Formats + +#### Dates, Times, and Duration + +These attributes apply to string instances. + +Date and time format names are derived from [RFC 3339, section 5.6](#rfc3339). +The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC +3339. + +Implementations supporting formats SHOULD implement support for the following +attributes: + +- *date-time:* A string instance is valid against this attribute if it is a + valid representation according to the "date-time" ABNF rule (referenced above) +- *date:* A string instance is valid against this attribute if it is a valid + representation according to the "full-date" ABNF rule (referenced above) +- *time:* A string instance is valid against this attribute if it is a valid + representation according to the "full-time" ABNF rule (referenced above) +- *duration:* A string instance is valid against this attribute if it is a valid + representation according to the "duration" ABNF rule (referenced above) + +Implementations MAY support additional attributes using the other format names +defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the +corresponding short form ("date" or "time" respectively) MUST be implemented, +and MUST behave identically. Implementations SHOULD NOT define extension +attributes with any name matching an RFC 3339 format unless it validates +according to the rules of that format.[^5] + +[^5]: There is not currently consensus on the need for supporting all RFC 3339 +formats, so this approach of reserving the namespace will encourage +experimentation without committing to the entire set. Either the format +implementation requirements will become more flexible in general, or these will +likely either be promoted to fully specified attributes or dropped. + +#### Email Addresses + +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid Internet +email address as follows: + +- *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section + 4.1.2](#rfc5321). +- *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, + section 3.3](#rfc6531). Note that all strings valid against the "email" + attribute are also valid against the "idn-email" attribute. + +#### Hostnames + +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid +representation for an Internet hostname as follows: + +- *hostname:* As defined by [RFC 1123, section 2.1](#rfc1123), including host + names produced using the Punycode algorithm specified in [RFC 5891, section + 4.4](#rfc5891). +- *idn-hostname:* As defined by either RFC 1123 as for hostname, or an + internationalized hostname as defined by [RFC 5890, section + 2.3.2.3](#rfc5890). Note that all strings valid against the "hostname" + attribute are also valid against the "idn-hostname" attribute. + +#### IP Addresses + +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid +representation of an IP address as follows: + +- *ipv4:* An IPv4 address according to the "dotted-quad" ABNF syntax as defined + in [RFC 2673, section 3.2](#rfc2673). +- *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](#rfc4291). + +#### Resource Identifiers These attributes apply to string instances. + +- *uri:* A string instance is valid against this attribute if it is a valid IRI, + according to [RFC3987](#rfc3987). +- *uri-reference:* A string instance is valid against this attribute if it is a + valid URI Reference (either a URI or a relative-reference), according to + [RFC3986](#rfc3986). +- *iri:* A string instance is valid against this attribute if it is a valid IRI, + according to [RFC3987](#rfc3987). +- *iri-reference:* A string instance is valid against this attribute if it is a + valid IRI Reference (either an IRI or a relative-reference), according to + [RFC3987](#rfc3987). +- *uuid:* A string instance is valid against this attribute if it is a valid + string representation of a UUID, according to [RFC4122](#rfc4122). + +Note that all valid URIs are valid IRIs, and all valid URI References are also +valid IRI References. + +Note also that the "uuid" format is for plain UUIDs, not UUIDs in URNs. An +example is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the +"uri" format, with a "pattern" regular expression of "^urn:uuid:" to indicate +the URI scheme and URN namespace. + +#### uri-template + +This attribute applies to string instances. + +A string instance is valid against this attribute if it is a valid URI Template +(of any level), according to [RFC6570](#rfc6570). + +Note that URI Templates may be used for IRIs; there is no separate IRI Template +specification. + +#### JSON Pointers + +These attributes apply to string instances. + +- *json-pointer:* A string instance is valid against this attribute if it is a + valid JSON string representation of a JSON Pointer, according to [RFC 6901, + section 5](#rfc6901). +- *relative-json-pointer:* A string instance is valid against this attribute if + it is a valid [Relative JSON Pointer](#relative-json-pointer). To allow for + both absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate + support for either format. + +#### regex + +This attribute applies to string instances. + +A regular expression, which SHOULD be valid according to the +[ECMA-262](#ecma262) regular expression dialect. + +Implementations that validate formats MUST accept at least the subset of +ECMA-262 defined in {{regexinterop}}), and SHOULD accept all valid ECMA-262 +expressions. + +## A Vocabulary for the Contents of String-Encoded Data {#content} + +### Foreword + +Annotations defined in this section indicate that an instance contains non-JSON +data encoded in a JSON string. + +These properties provide additional information required to interpret JSON data +as rich multimedia documents. They describe the type of content, how it is +encoded, and/or how it may be validated. They do not function as validation +assertions; a malformed string-encoded document MUST NOT cause the containing +instance to be considered invalid. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Content vocabulary, is: +`https://json-schema.org/draft/next/vocab/content`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/content`. + +### Implementation Requirements + +Due to security and performance concerns, as well as the open-ended nature of +possible content types, implementations MUST NOT automatically decode, parse, +and/or validate the string contents. Applications are expected to use these +annotations to invoke the appropriate libraries separately. + +All keywords in this section apply only to strings, and have no effect on other +data types. + +### `contentEncoding` + +If the instance value is a string, this property defines that the string SHOULD +be interpreted as encoded binary data and applications wishing to decode it +SHOULD do so using the encoding named by this property. + +Possible values indicating base 16, 32, and 64 encodings with several variations +are listed in [RFC 4648](#rfc4648). Additionally, sections 6.7 and 6.8 of [RFC +2045](#rfc2045) provide encodings used in MIME. This keyword is derived from +MIME's Content-Transfer-Encoding header, which was designed to map binary data +into ASCII characters. It is not related to HTTP's Content-Encoding header, +which is used to encode (e.g. compress or encrypt) the content of HTTP request +and responses. + +As "base64" is defined in both RFCs, the definition from RFC 4648 SHOULD be +assumed unless the string is specifically intended for use in a MIME context. +Note that all of these encodings result in strings consisting only of 7-bit +ASCII characters. Therefore, this keyword has no meaning for strings containing +characters outside of that range. + +If this keyword is absent, but `contentMediaType` is present, this indicates +that the encoding is the identity encoding, meaning that no transformation was +needed in order to represent the content in a UTF-8 string. + +The value of this property MUST be a string. + +### `contentMediaType` + +If the instance is a string, this property indicates the media type of the +contents of the string. If `contentEncoding` is present, this property describes +the decoded string. + +The value of this property MUST be a string, which MUST be a media type, as +defined by [RFC 2046](#rfc2046). + +### `contentSchema` + +If the instance is a string, and if `contentMediaType` is present, this property +contains a schema which describes the structure of the string. + +This keyword MAY be used with any media type that can be mapped into JSON +Schema's data model. Specifying such mappings is outside of the scope of this +specification. + +The value of this property MUST be a valid JSON schema. It SHOULD be ignored if +`contentMediaType` is not present. Accessing the schema through the schema +location IRI included as part of the annotation will ensure that it is correctly +processed as a subschema. Using the extracted annotation value directly is only +safe if the schema is an embedded resource with both `$schema` and an +absolute-IRI `$id`. + +### Example + +Here is an example schema, illustrating the use of `contentEncoding` and +`contentMediaType`: + +```jsonschema +{ + "type": "string", + "contentEncoding": "base64", + "contentMediaType": "image/png" +} +``` + +Instances described by this schema are expected to be strings, and their values +should be interpretable as base64-encoded PNG images. + +Another example: + +```jsonschema +{ + "type": "string", + "contentMediaType": "text/html" +} +``` + +Instances described by this schema are expected to be strings containing HTML, +using whatever character set the JSON string was decoded into. Per section 8.1 +of [RFC 8259](#rfc8259), outside of an entirely closed system, this MUST be +UTF-8. + +This example describes a JWT that is MACed using the HMAC SHA-256 algorithm, and +requires the "iss" and "exp" fields in its claim set. + +```jsonschema +{ + "type": "string", + "contentMediaType": "application/jwt", + "contentSchema": { + "type": "array", + "minItems": 2, + "prefixItems": [ + { + "const": { + "typ": "JWT", + "alg": "HS256" + } + }, + { + "type": "object", + "required": ["iss", "exp"], + "properties": { + "iss": {"type": "string"}, + "exp": {"type": "integer"} + } + } + ] + } +} +``` + +Note that `contentEncoding` does not appear. While the `application/jwt` media +type makes use of base64url encoding, that is defined by the media type, which +determines how the JWT string is decoded into a list of two JSON data +structures: first the header, and then the payload. Since the JWT media type +ensures that the JWT can be represented in a JSON string, there is no need for +further encoding or decoding. + +## A Vocabulary for Basic Meta-Data Annotations These general-purpose annotation +keywords provide commonly used information for documentation and user interface +display purposes. They are not intended to form a comprehensive set of features. +Rather, additional vocabularies can be defined for more complex annotation-based +applications. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: +`https://json-schema.org/draft/next/vocab/meta-data`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/meta-data`. + +### `title` and `description` + +The value of both of these keywords MUST be a string. + +Both of these keywords can be used to decorate a user interface with information +about the data produced by this user interface. A title will preferably be +short, whereas a description will provide explanation about the purpose of the +instance described by this schema. + +### `default` + +There are no restrictions placed on the value of this keyword. When multiple +occurrences of this keyword are applicable to a single sub-instance, +implementations SHOULD remove duplicates. + +This keyword can be used to supply a default JSON value associated with a +particular schema. It is RECOMMENDED that a default value be valid against the +associated schema. + +### `deprecated` + +The value of this keyword MUST be a boolean. When multiple occurrences of this +keyword are applicable to a single sub-instance, applications SHOULD consider +the instance location to be deprecated if any occurrence specifies a true value. + +If `deprecated` has a value of boolean true, it indicates that applications +SHOULD refrain from usage of the declared property. It MAY mean the property is +going to be removed in the future. + +A root schema containing `deprecated` with a value of true indicates that the +entire resource being described MAY be removed in the future. + +The `deprecated` keyword applies to each instance location to which the schema +object containing the keyword successfully applies. This can result in scenarios +where every array item or object property is deprecated even though the +containing array or object is not. + +Omitting this keyword has the same behavior as a value of false. + +### `readOnly` and `writeOnly` + +The value of these keywords MUST be a boolean. When multiple occurrences of +these keywords are applicable to a single sub-instance, the resulting behavior +SHOULD be as for a true value if any occurrence specifies a true value, and +SHOULD be as for a false value otherwise. + +If `readOnly` has a value of boolean true, it indicates that the value of the +instance is managed exclusively by the owning authority, and attempts by an +application to modify the value of this property are expected to be ignored or +rejected by that owning authority. + +An instance document that is marked as `readOnly` for the entire document MAY be +ignored if sent to the owning authority, or MAY result in an error, at the +authority's discretion. + +If `writeOnly` has a value of boolean true, it indicates that the value is never +present when the instance is retrieved from the owning authority. It can be +present when sent to the owning authority to update or create the document (or +the resource it represents), but it will not be included in any updated or newly +created version of the instance. + +An instance document that is marked as `writeOnly` for the entire document MAY +be returned as a blank document of some sort, or MAY produce an error upon +retrieval, or have the retrieval request ignored, at the authority's discretion. + +For example, `readOnly` would be used to mark a database-generated serial number +as read-only, while `writeOnly` would be used to mark a password input field. + +These keywords can be used to assist in user interface instance generation. In +particular, an application MAY choose to use a widget that hides input values as +they are typed for write-only fields. + +Omitting these keywords has the same behavior as values of false. + +### `examples` + +The value of this keyword MUST be an array. There are no restrictions placed on +the values within the array. When multiple occurrences of this keyword are +applicable to a single sub-instance, implementations MUST provide a flat array +of all values rather than an array of arrays. + +This keyword can be used to provide sample JSON values associated with a +particular schema, for the purpose of illustrating usage. It is RECOMMENDED that +these values be valid against the associated schema. + +Implementations MAY use the value(s) of `default`, if present, as an additional +example. If `examples` is absent, `default` MAY still be used in this manner. + +## Security Considerations {#security} + +JSON Schema validation defines a vocabulary for JSON Schema core and concerns +all the security considerations listed there. + +JSON Schema validation allows the use of Regular Expressions, which have +numerous different (often incompatible) implementations. Some implementations +allow the embedding of arbitrary code, which is outside the scope of JSON Schema +and MUST NOT be permitted. Regular expressions can often also be crafted to be +extremely expensive to compute (with so-called "catastrophic backtracking"), +resulting in a denial-of-service attack. + +Implementations that support validating or otherwise evaluating instance string +data based on `contentEncoding` and/or `contentMediaType` are at risk of +evaluating data in an unsafe way based on misleading information. Applications +can mitigate this risk by only performing such processing when a relationship +between the schema and instance is established (e.g., they share the same +authority). + +Processing a media type or encoding is subject to the security considerations of +that media type or encoding. For example, the security considerations of [RFC +4329 Scripting Media Types](#rfc4329) apply when processing JavaScript or +ECMAScript encoded within a JSON string. + +## References + +### Normative References + +#### [RFC2119] {#rfc2119} + +Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, +RFC 2119, DOI 10.17487/RFC2119, March 1997, +<>. + +#### [RFC1123] {#rfc1123} + +Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", +STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, +<>. + +#### [RFC2045] {#rfc2045} + +Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part +One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, +November 1996, <>. + +#### [RFC2046] {#rfc2046} + +Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part +Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, +<>. + +#### [RFC2673] {#rfc2673} + +Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI +10.17487/RFC2673, August 1999, <>. + +#### [RFC3339] {#rfc3339} + +Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, +DOI 10.17487/RFC3339, July 2002, <>. + +#### [RFC3986] {#rfc3986} + +Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier +(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, +<>. + +#### [RFC3987] {#rfc3987} + +Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC +3987, DOI 10.17487/RFC3987, January 2005, +<>. + +#### [RFC4122] {#rfc4122} + +Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) +URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, +<>. + +#### [RFC4291] {#rfc4291} + +Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI +10.17487/RFC4291, February 2006, <>. + +#### [RFC4648] {#rfc4648} + +Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI +10.17487/RFC4648, October 2006, <>. + +#### [RFC5321] {#rfc5321} + +Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, +October 2008, <>. + +#### [RFC5890] {#rfc5890} + +Klensin, J., "Internationalized Domain Names for Applications (IDNA): +Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August +2010, <>. + +#### [RFC5891] {#rfc5891} + +Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", +RFC 5891, DOI 10.17487/RFC5891, August 2010, +<>. + +#### [RFC6570] {#rfc6570} + +Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI +Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, +<>. + +#### [RFC6531] {#rfc6531} + +Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI +10.17487/RFC6531, February 2012, <>. + +#### [RFC6901] {#rfc6901} + +Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation +(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, +<>. + +#### [RFC8259] {#rfc8259} + +Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", +STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, +<>. + +#### [ecma262] {#ecma262} + +ECMA-262, 11th edition specification", June 2020, +<>. + +#### [relative-json-pointer] {#relative-json-pointer} + +Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", Work in +Progress, Internet-Draft, draft-handrews-relative-json-pointer-01, December +2020, +<>. + +#### [json-schema] {#json-schema} + +Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type +for Describing JSON Documents", Work in Progress, Internet-Draft, +draft-bhutton-json-schema-01, June 2022, +<>. + +### Informative References + +#### [RFC4329] {#rfc4329} + +Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April +2006, <>. + +## [Appendix] Keywords Moved from Validation to Core + +Several keywords have been moved from this document into the [Core +Specification](#json-schema) starting with draft 2019-09, in some cases with +re-naming or other changes. This affects the following former validation +keywords: + +- *`definitions`* Renamed to `$defs` to match `$ref` and be shorter to type. + Schema vocabulary authors SHOULD NOT define a `definitions` keyword with + different behavior in order to avoid invalidating schemas that still use the + older name. While `definitions` is absent in the single-vocabulary + meta-schemas referenced by this document, it remains present in the default + meta-schema, and implementations SHOULD assume that `$defs` and `definitions` + have the same behavior when that meta-schema is used. +- *`allOf`, `anyOf`, `oneOf`, `not`, `if`, `then`, `else`, `items`, + `additionalItems`, `contains`, `propertyNames`, `properties`, + `patternProperties`, `additionalProperties`* All of these keywords apply + subschemas to the instance and combine their results, without asserting any + conditions of their own. Without assertion keywords, these applicators can + only cause assertion failures by using the false boolean schema, or by + inverting the result of the true boolean schema (or equivalent schema + objects). For this reason, they are better defined as a generic mechanism on + which validation, hyper-schema, and extension vocabularies can all be based. +- *`maxContains`, `minContains`* These keywords modify the behavior of + `contains`, and are therefore grouped with it in the applicator vocabulary. +- *`dependencies`* This keyword had two different modes of behavior, which made + it relatively challenging to implement and reason about. The schema form has + been moved to Core and renamed to `dependentSchemas`, as part of the + applicator vocabulary. It is analogous to `properties`, except that instead of + applying its subschema to the property value, it applies it to the object + containing the property. The property name array form is retained here and + renamed to `dependentRequired`, as it is an assertion which is a shortcut for + the conditional use of the `required` assertion keyword. + +## [Appendix] Acknowledgments + +Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry +Andrews for their work on the initial drafts of JSON Schema. + +Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Evgeny Poberezkin, Brad +Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil +Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches +to the document. + +## [Appendix] ChangeLog[^6] +[^6]: This section to be removed before leaving Internet-Draft status. + +- *draft-next* + - Use IRIs instead of URIs +- *draft-bhutton-json-schema-validation-01* + - Improve and clarify the `minContains` keyword explanation + - Remove the use of "production" in favour of "ABNF rule" +- *draft-bhutton-json-schema-validation-00* + - Correct email format RFC reference to 5321 instead of 5322 + - Clarified the set and meaning of `contentEncoding` values + - Reference ECMA-262, 11th edition for regular expression support + - Split `format` into an annotation only vocabulary and an assertion + vocabulary + - Clarify `deprecated` when applicable to arrays +- *draft-handrews-json-schema-validation-02* + - Grouped keywords into formal vocabularies + - Update `format` implementation requirements in terms of vocabularies + - By default, `format` MUST NOT be validated, although validation can be + enabled + - A vocabulary declaration can be used to require `format` validation + - Moved `definitions` to the core spec as `$defs` + - Moved applicator keywords to the core spec + - Renamed the array form of `dependencies` to `dependentRequired`, moved the +schema form to the core spec + - Specified all `content*` keywords as annotations, not assertions + - Added `contentSchema` to allow applying a schema to a string-encoded + document + - Also allow RFC 4648 encodings in `contentEncoding` + - Added `minContains` and `maxContains` + - Update RFC reference for nhostname" and "idn-hostname" + - Add "uuid" and "duration" formats +- *draft-handrews-json-schema-validation-01* + - This draft is purely a clarification with no functional changes + - Provided the general principle behind ignoring annotations under `not` and + similar cases + - Clarified `if`/`then`/`else` validation interactions + - Clarified `if`/`then`/`else` behavior for annotation + - Minor formatting and cross-referencing improvements +- *draft-handrews-json-schema-validation-00* + - Added `if`/`then`/`else` + - Classify keywords as assertions or annotations per the core spec + - Warn of possibly removing `dependencies` in the future + - Grouped validation keywords into sub-sections for readability + - Moved `readOnly` from hyper-schema to validation meta-data + - Added `writeOnly` + - Added string-encoded media section, with former hyper-schema `media` + keywords + - Restored "regex" format (removal was unintentional) + - Added "date" and "time" formats, and reserved additional RFC 3339 format + names + - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" + - Clarify that "json-pointer" format means string encoding, not URI fragment + - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` + - Move format syntax references into Normative References + - JSON is a normative requirement +- *draft-wright-json-schema-validation-01* + - Standardized on hyphenated format names with full words ("uriref" becomes + "uri-reference") + - Add the formats "uri-template" and "json-pointer" + - Changed `exclusiveMaximum`/`exclusiveMinimum` from boolean modifiers of + `maximum`/`minimum` to independent numeric fields. + - Split the additionalItems/items into two sections + - Reworked properties/patternProperties/additionalProperties definition + - Added `examples` keyword + - Added `contains` keyword + - Allow empty `required` and `dependencies` arrays + - Fixed `type` reference to primitive types + - Added `const` keyword + - Added `propertyNames` keyword +- *draft-wright-json-schema-validation-00* + - Added additional security considerations + - Removed reference to "latest version" meta-schema, use numbered version + instead + - Rephrased many keyword definitions for brevity + - Added "uriref" format that also allows relative URI references +- *draft-fge-json-schema-validation-00* + - Initial draft. + - Salvaged from draft v3. + - Redefine the `required` keyword. + - Remove `extends`, `disallow` + - Add `anyOf`, `allOf`, `oneOf`, `not`, `definitions`, `minProperties`, + `maxProperties`. + - `dependencies` member values can no longer be single strings; at least one + element is required in a property dependency array. + - Rename `divisibleBy` to `multipleOf`. + - `type` arrays can no longer have schemas; remove `any` as a possible + value. + - Rework the `format` section; make support optional. + - `format": remove attributes "phone", "style", "color"; rename "ip-address" + to "ipv4"; add references for all attributes. + - Provide algorithms to calculate schema(s) for array/object instances. + - Add interoperability considerations. + +## Authors' Addresses +| Author | Company | Email | URI | +|--------------------------|---------|----------------------|--------------------------| +| Austin Wright (*editor*) | | | | +| Ben Hutton (*editor*) | Postman | | | diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml deleted file mode 100644 index 65902b4e..00000000 --- a/jsonschema-validation.xml +++ /dev/null @@ -1,1492 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -]> - - - - - - - - - - - - JSON Schema Validation: A Vocabulary for Structural Validation of JSON - - - -
- aaa@bzfx.net -
- - - - Postman -
- ben@jsonschema.dev - https://jsonschema.dev -
- - - - Internet Engineering Task Force - JSON - Schema - validation - - - - JSON Schema (application/schema+json) has several purposes, one of which is JSON - instance validation. - This document specifies a vocabulary for JSON Schema to describe the meaning of JSON - documents, provide hints for user interfaces working with JSON data, and to make - assertions about what a valid document must look like. - - - - - - The issues list for this draft can be found at - . - - - For additional information, see . - - - To provide feedback, use this issue tracker, the communication methods listed on the - homepage, or email the document editors. - - - - - -
- - JSON Schema can be used to require that a given JSON document (an instance) - satisfies a certain number of criteria. These criteria are asserted by using - keywords described in this specification. In addition, a set of keywords - is also defined to assist in interactive user interface instance generation. - - - This specification will use the concepts, syntax, and terminology defined - by the JSON Schema core specification. - -
- -
- - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. - - - This specification uses the term "container instance" to refer to both array and - object instances. It uses the term "children instances" to refer to array elements - or object member values. - - - Elements in an array value are said to be unique if no two elements of this array - are equal. - -
- -
- - JSON Schema validation asserts constraints on the structure of instance data. - An instance location that satisfies all asserted constraints is then - annotated with any keywords that contain non-assertion information, - such as descriptive metadata and usage hints. If all locations within - the instance satisfy all asserted constraints, then the instance is - said to be valid against the schema. - - - Each schema object is independently evaluated against each instance location - to which it applies. This greatly simplifies the implementation requirements - for validators by ensuring that they do not need to maintain state across - the document-wide validation process. - - - This specification defines a set of assertion keywords, as well as a small vocabulary - of metadata keywords that can be used to annotate the JSON instance with - useful information. The keyword is intended primarily - as an annotation, but can optionally be used as an assertion. The - keywords are annotations for working with documents - embedded as JSON strings. - -
- -
- -
- - It should be noted that the nul character (\u0000) is valid in a JSON string. An - instance to validate may contain a string value with this character, regardless - of the ability of the underlying programming language to deal with such data. - -
- -
- - The JSON specification allows numbers with arbitrary precision, and JSON Schema - does not add any such bounds. - This means that numeric instances processed by JSON Schema can be arbitrarily large and/or - have an arbitrarily long decimal part, regardless of the ability of the - underlying programming language to deal with such data. - -
- -
- - Keywords that use regular expressions, or constrain the instance value - to be a regular expression, are subject to the interoperability - considerations for regular expressions in the - JSON Schema Core specification. - -
- -
- -
- - The current IRI for the default JSON Schema dialect meta-schema is - . - For schema author convenience, this meta-schema describes a dialect - consisting of all vocabularies - defined in this specification and the JSON Schema Core specification, - as well as two former keywords which are reserved for a transitional period. - Individual vocabulary and vocabulary meta-schema IRIs are given for - each section below. Certain vocabularies are optional to support, which - is explained in detail in the relevant sections. - - - Updated vocabulary and meta-schema IRIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider IRIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
- -
- - Validation keywords in a schema impose requirements for successful validation of an - instance. These keywords are all assertions without any annotation behavior. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/next/vocab/validation>. - - - The current IRI for the corresponding meta-schema is: - . - - -
-
- - The value of this keyword MUST be either a string or an array. If it is - an array, elements of the array MUST be strings and MUST be unique. - - - String values MUST be one of the six primitive types - ("null", "boolean", "object", "array", "number", or "string"), - or "integer" which matches any number with a zero fractional part. - - - If the value of "type" is a string, then an instance validates successfully if - its type matches the type represented by the value of the string. - - If the value of "type" is an array, then an instance validates successfully if - its type matches any of the types indicated by the strings in the array. - -
- -
- - The value of this keyword MUST be an array. This array SHOULD have at - least one element. Elements in the array SHOULD be unique. - - - An instance validates successfully against this keyword if its value is - equal to one of the elements in this keyword's array value. - - - Elements in the array might be of any type, including null. - -
- -
- - The value of this keyword MAY be of any type, including null. - - - Use of this keyword is functionally equivalent to an - "enum" with a single value. - - - An instance validates successfully against this keyword if its value is - equal to the value of the keyword. - -
-
- -
-
- - The value of "multipleOf" MUST be a number, strictly greater than 0. - - - A numeric instance is valid only if division by this keyword's value results in - an integer. - -
- -
- - The value of "maximum" MUST be a number, representing an inclusive upper limit - for a numeric instance. - - - If the instance is a number, then this keyword validates only if the instance is - less than or exactly equal to "maximum". - -
- -
- - The value of "exclusiveMaximum" MUST be a number, representing an exclusive upper - limit for a numeric instance. - - - If the instance is a number, then the instance is valid only if it has a value - strictly less than (not equal to) "exclusiveMaximum". - -
- -
- - The value of "minimum" MUST be a number, representing an inclusive lower limit - for a numeric instance. - - - If the instance is a number, then this keyword validates only if the instance is - greater than or exactly equal to "minimum". - -
- -
- - The value of "exclusiveMinimum" MUST be a number, representing an exclusive lower - limit for a numeric instance. - - - If the instance is a number, then the instance is valid only if it has a value - strictly greater than (not equal to) "exclusiveMinimum". - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - A string instance is valid against this keyword if its - length is less than, or equal to, the value of this keyword. - - - The length of a string instance is defined as the number of its - characters as defined by RFC 8259. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - A string instance is valid against this keyword if its - length is greater than, or equal to, the value of this keyword. - - - - The length of a string instance is defined as the number of its - characters as defined by RFC 8259. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be a string. This string SHOULD be a - valid regular expression, according to the ECMA-262 regular expression - dialect. - - - A string instance is considered valid if the regular - expression matches the instance successfully. Recall: regular - expressions are not implicitly anchored. - -
-
- -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An array instance is valid against "maxItems" if its size is - less than, or equal to, the value of this keyword. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An array instance is valid against "minItems" if its size is - greater than, or equal to, the value of this keyword. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be a boolean. - - - If this keyword has boolean value false, the instance validates - successfully. If it has boolean value true, the instance validates - successfully if all of its elements are unique. - - - Omitting this keyword has the same behavior as a value of false. - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - - An object instance is valid against "maxProperties" if its - number of properties is less than, or equal to, the value of this - keyword. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An object instance is valid against "minProperties" if its - number of properties is greater than, or equal to, the value of this - keyword. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be an array. - Elements of this array, if any, MUST be strings, and MUST be unique. - - - An object instance is valid against this keyword if every item in the array is - the name of a property in the instance. - - - Omitting this keyword has the same behavior as an empty array. - -
- -
- - The value of this keyword MUST be an object. Properties in - this object, if any, MUST be arrays. Elements in each array, - if any, MUST be strings, and MUST be unique. - - - This keyword specifies properties that are required if a specific - other property is present. Their requirement is dependent on the - presence of the other property. - - - Validation succeeds if, for each name that appears in both - the instance and as a name within this keyword's value, every - item in the corresponding array is also the name of a property - in the instance. - - - Omitting this keyword has the same behavior as an empty object. - -
-
-
- -
- -
- - Structural validation alone may be insufficient to allow an application to correctly - utilize certain values. The "format" annotation keyword is defined to allow schema - authors to convey semantic information for a fixed subset of values which are - accurately described by authoritative resources, be they RFCs or other external - specifications. - - - - The value of this keyword is called a format attribute. It MUST be a string. A - format attribute can generally only validate a given set of instance types. If - the type of the instance to validate is not in this set, validation for this - format attribute and instance SHOULD succeed. All format attributes defined - in this section apply to strings, but a format attribute can be specified - to apply to any instance types defined in the data model defined in the - core JSON Schema. - - Note that the "type" keyword in this specification defines an "integer" type - which is not part of the data model. Therefore a format attribute can be - limited to numbers, but not specifically to integers. However, a numeric - format can be used alongside the "type" keyword with a value of "integer", - or could be explicitly defined to always pass if the number is not an integer, - which produces essentially the same behavior as only applying to integers. - - - - - The current IRI for this vocabulary, known as the Format-Annotation vocabulary, is: - <https://json-schema.org/draft/next/vocab/format-annotation>. The current - IRI for the corresponding meta-schema is: - . - Implementing support for this vocabulary is REQUIRED. - - - In addition to the Format-Annotation vocabulary, a secondary vocabulary is available - for custom meta-schemas that defines "format" as an assertion. The IRI for the - Format-Assertion vocabulary, is: - <https://json-schema.org/draft/next/vocab/format-assertion>. The current - IRI for the corresponding meta-schema is: - . - Implementing support for the Format-Assertion vocabulary is OPTIONAL. - - - Specifying both the Format-Annotation and the Format-Assertion vocabularies is functionally - equivalent to specifying only the Format-Assertion vocabulary since its requirements - are a superset of the Format-Annotation vocabulary. - -
- -
- - The "format" keyword functions as defined by the vocabulary which is referenced. - - -
- - The value of format MUST be collected as an annotation, if the implementation - supports annotation collection. This enables application-level validation when - schema validation is unavailable or inadequate. - - - Implementations MAY still treat "format" as an assertion in addition to an - annotation and attempt to validate the value's conformance to the specified - semantics. The implementation MUST provide options to enable and disable such - evaluation and MUST be disabled by default. Implementations SHOULD document - their level of support for such validation. - - Specifying the Format-Annotation vocabulary and enabling validation in an - implementation should not be viewed as being equivalent to specifying - the Format-Assertion vocabulary since implementations are not required to - provide full validation support when the Format-Assertion vocabulary - is not specified. - - - - When the implementation is configured for assertion behavior, it: - - - SHOULD provide an implementation-specific best effort validation - for each format attribute defined below; - - - MAY choose to implement validation of any or all format attributes - as a no-op by always producing a validation result of true; - - - - This matches the current reality of implementations, which provide - widely varying levels of validation, including no validation at all, - for some or all format attributes. It is also designed to encourage - relying only on the annotation behavior and performing semantic - validation in the application, which is the recommended best practice. - - -
- -
- - When the Format-Assertion vocabulary is declared with a value of true, - implementations MUST provide full validation support for all of the formats - defined by this specificaion. Implementations that cannot provide full - validation support MUST refuse to process the schema. - - - An implementation that supports the Format-Assertion vocabulary: - - - MUST still collect "format" as an annotation if the implementation - supports annotation collection; - - - MUST evaluate "format" as an assertion; - - - MUST implement syntactic validation for all format attributes defined - in this specification, and for any additional format attributes that - it recognizes, such that there exist possible instance values - of the correct type that will fail validation. - - - The requirement for minimal validation of format attributes is intentionally - vague and permissive, due to the complexity involved in many of the attributes. - Note in particular that the requirement is limited to syntactic checking; it is - not to be expected that an implementation would send an email, attempt to connect - to a URL, or otherwise check the existence of an entity identified by a format - instance. - - The expectation is that for simple formats such as date-time, syntactic - validation will be thorough. For a complex format such as email addresses, - which are the amalgamation of various standards and numerous adjustments - over time, with obscure and/or obsolete rules that may or may not be - restricted by other applications making use of the value, a minimal validation - is sufficient. For example, an instance string that does not contain - an "@" is clearly not a valid email address, and an "email" or "hostname" - containing characters outside of 7-bit ASCII is likewise clearly invalid. - - - - It is RECOMMENDED that implementations use a common parsing library for each format, - or a well-known regular expression. Implementations SHOULD clearly document - how and to what degree each format attribute is validated. - - - The standard core and validation meta-schema - includes this vocabulary in its "$vocabulary" keyword with a value of false, - since by default implementations are not required to support this keyword - as an assertion. Supporting the format vocabulary with a value of true is - understood to greatly increase code size and in some cases execution time, - and will not be appropriate for all implementations. - -
-
- - Implementations MAY support custom format attributes. Save for agreement between - parties, schema authors SHALL NOT expect a peer implementation to support such - custom format attributes. An implementation MUST NOT fail to collect unknown formats - as annotations. When the Format-Assertion vocabulary is specified, implementations - MUST fail upon encountering unknown formats. - - - Vocabularies do not support specifically declaring different value sets for keywords. - Due to this limitation, and the historically uneven implementation of this keyword, - it is RECOMMENDED to define additional keywords in a custom vocabulary rather than - additional format attributes if interoperability is desired. - -
-
- -
- -
- - These attributes apply to string instances. - - - Date and time format names are derived from - RFC 3339, section 5.6. - The duration format is from the ISO 8601 ABNF as given - in Appendix A of RFC 3339. - - - Implementations supporting formats SHOULD implement support for - the following attributes: - - - A string instance is valid against this attribute if it is - a valid representation according to the "date-time' ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "full-date" ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "full-time" ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "duration" ABNF rule - (referenced above) - - - - - Implementations MAY support additional attributes using the other - format names defined anywhere in that RFC. If "full-date" or "full-time" - are implemented, the corresponding short form ("date" or "time" - respectively) MUST be implemented, and MUST behave identically. - Implementations SHOULD NOT define extension attributes - with any name matching an RFC 3339 format unless it validates - according to the rules of that format. - - There is not currently consensus on the need for supporting - all RFC 3339 formats, so this approach of reserving the - namespace will encourage experimentation without committing - to the entire set. Either the format implementation requirements - will become more flexible in general, or these will likely - either be promoted to fully specified attributes or dropped. - - -
- -
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - Internet email address as follows: - - - As defined by the "Mailbox" ABNF rule in - RFC 5321, section 4.1.2. - - - As defined by the extended "Mailbox" ABNF rule in - RFC 6531, section 3.3. - - - Note that all strings valid against the "email" attribute are also - valid against the "idn-email" attribute. - -
-
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - representation for an Internet hostname as follows: - - - As defined by RFC 1123, section 2.1, - including host names produced using the Punycode algorithm - specified in RFC 5891, section 4.4. - - - As defined by either RFC 1123 as for hostname, or an - internationalized hostname as defined by - RFC 5890, section 2.3.2.3. - - - Note that all strings valid against the "hostname" attribute are also - valid against the "idn-hostname" attribute. - -
- -
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - representation of an IP address as follows: - - - An IPv4 address according to the "dotted-quad" ABNF - syntax as defined in - RFC 2673, section 3.2. - - - An IPv6 address as defined in - RFC 4291, section 2.2. - - - -
- -
- - These attributes apply to string instances. - - - - - A string instance is valid against this attribute if it is - a valid IRI, according to . - - - A string instance is valid against this attribute if it is a valid URI - Reference (either a URI or a relative-reference), - according to . - - - A string instance is valid against this attribute if it is - a valid IRI, according to . - - - A string instance is valid against this attribute if it is a valid IRI - Reference (either an IRI or a relative-reference), - according to . - - - A string instance is valid against this attribute if it is a valid - string representation of a UUID, according to . - - - - - Note that all valid URIs are valid IRIs, and all valid URI References are - also valid IRI References. - - - Note also that the "uuid" format is for plain UUIDs, not UUIDs in URNs. An example - is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the "uri" format, - with a "pattern" regular expression of "^urn:uuid:" to indicate the URI scheme and - URN namespace. - -
- -
- - This attribute applies to string instances. - - - A string instance is valid against this attribute if it is a valid URI Template - (of any level), according to . - - - Note that URI Templates may be used for IRIs; there is no separate - IRI Template specification. - -
- -
- - These attributes apply to string instances. - - - - - A string instance is valid against this attribute if it - is a valid JSON string representation of a JSON Pointer, - according to RFC 6901, section 5. - - - A string instance is valid against this attribute if it is a valid - Relative JSON Pointer. - - - To allow for both absolute and relative JSON Pointers, use "anyOf" or - "oneOf" to indicate support for either format. - -
-
- - This attribute applies to string instances. - - - 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 of this specification, and SHOULD accept all valid ECMA-262 expressions. - -
-
-
- -
- -
- - Annotations defined in this section indicate that an instance contains - non-JSON data encoded in a JSON string. - - - These properties provide additional information required to interpret JSON data - as rich multimedia documents. They describe the type of content, how it is encoded, - and/or how it may be validated. They do not function as validation assertions; - a malformed string-encoded document MUST NOT cause the containing instance - to be considered invalid. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/next/vocab/content>. - - - The current IRI for the corresponding meta-schema is: - . - -
- -
- - Due to security and performance concerns, as well as the open-ended nature of - possible content types, implementations MUST NOT automatically decode, parse, - and/or validate the string contents. Applications are expected to use these - annotations to invoke the appropriate libraries separately. - - - All keywords in this section apply only to strings, and have no - effect on other data types. - -
- -
- - - If the instance value is a string, this property defines that the string - SHOULD be interpreted as encoded binary data and applications wishing - to decode it SHOULD do so using the encoding named by this property. - - - - Possible values indicating base 16, 32, and 64 encodings with several - variations are listed in RFC 4648. Additionally, - sections 6.7 and 6.8 of RFC 2045 provide - encodings used in MIME. This keyword is derived from MIME's - Content-Transfer-Encoding header, which was designed to map binary data - into ASCII characters. It is not related to HTTP's Content-Encoding header, - which is used to encode (e.g. compress or encrypt) - the content of HTTP request and responses. - - - As "base64" is defined in both RFCs, the definition - from RFC 4648 SHOULD be assumed unless the string is specifically intended - for use in a MIME context. Note that all of these encodings result in - strings consisting only of 7-bit ASCII characters. Therefore, this keyword - has no meaning for strings containing characters outside of that range. - - - - If this keyword is absent, but "contentMediaType" is present, this - indicates that the encoding is the identity encoding, meaning that - no transformation was needed in order to represent the content in - a UTF-8 string. - - - - The value of this property MUST be a string. - -
- -
- - If the instance is a string, this property indicates the media type - of the contents of the string. If "contentEncoding" is present, - this property describes the decoded string. - - - The value of this property MUST be a string, which MUST be a media type, - as defined by RFC 2046. - -
- -
- - If the instance is a string, and if "contentMediaType" is present, this - property contains a schema which describes the structure of the string. - - - This keyword MAY be used with any media type that can be mapped into - JSON Schema's data model. Specifying such mappings is outside of the - scope of this specification. - - - The value of this property MUST be a valid JSON schema. It SHOULD be ignored if - "contentMediaType" is not present. Accessing the schema through the schema location - IRI included as part of the annotation will ensure that it is correctly processed - as a subschema. Using the extracted annotation value directly is only safe if - the schema is an embedded resource with both "$schema" and an absolute-IRI "$id". - -
- -
-
- - Here is an example schema, illustrating the use of "contentEncoding" and - "contentMediaType": - - - - - - Instances described by this schema are expected to be strings, - and their values should be interpretable as base64-encoded PNG images. - -
- -
- - Another example: - - - - - - Instances described by this schema are expected to be strings containing HTML, - using whatever character set the JSON string was decoded into. - Per section 8.1 of - RFC 8259, outside of an entirely closed - system, this MUST be UTF-8. - -
- -
- - This example describes a JWT that is MACed using the HMAC SHA-256 - algorithm, and requires the "iss" and "exp" fields in its claim set. - - - - - - Note that "contentEncoding" does not appear. While the "application/jwt" - media type makes use of base64url encoding, that is defined by the media - type, which determines how the JWT string is decoded into a list of two - JSON data structures: first the header, and then the payload. Since the - JWT media type ensures that the JWT can be represented in a JSON string, - there is no need for further encoding or decoding. - -
-
- -
- -
- - These general-purpose annotation keywords provide commonly used information - for documentation and user interface display purposes. They are not intended - to form a comprehensive set of features. Rather, additional vocabularies - can be defined for more complex annotation-based applications. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/next/vocab/meta-data>. - - - The current IRI for the corresponding meta-schema is: - . - - -
- - The value of both of these keywords MUST be a string. - - - Both of these keywords can be used to decorate a user interface with - information about the data produced by this user interface. A title will - preferably be short, whereas a description will provide explanation about - the purpose of the instance described by this schema. - -
- -
- - There are no restrictions placed on the value of this keyword. When - multiple occurrences of this keyword are applicable to a single - sub-instance, implementations SHOULD remove duplicates. - - - This keyword can be used to supply a default JSON value associated with a - particular schema. It is RECOMMENDED that a default value be valid against - the associated schema. - -
- -
- - The value of this keyword MUST be a boolean. When multiple occurrences - of this keyword are applicable to a single sub-instance, applications - SHOULD consider the instance location to be deprecated if any occurrence - specifies a true value. - - - If "deprecated" has a value of boolean true, it indicates that applications - SHOULD refrain from usage of the declared property. It MAY mean the property - is going to be removed in the future. - - - A root schema containing "deprecated" with a value of true indicates that - the entire resource being described MAY be removed in the future. - - - The "deprecated" keyword applies to each instance location to which the - schema object containing the keyword successfully applies. This can - result in scenarios where every array item or object property - is deprecated even though the containing array or object is not. - - - Omitting this keyword has the same behavior as a value of false. - -
- -
- - The value of these keywords MUST be a boolean. When multiple occurrences - of these keywords are applicable to a single sub-instance, the resulting - behavior SHOULD be as for a true value if any occurrence specifies a true value, - and SHOULD be as for a false value otherwise. - - - If "readOnly" has a value of boolean true, it indicates that the value - of the instance is managed exclusively by the owning authority, and - attempts by an application to modify the value of this property are - expected to be ignored or rejected by that owning authority. - - - An instance document that is marked as "readOnly" for the entire document - MAY be ignored if sent to the owning authority, or MAY result in an - error, at the authority's discretion. - - - If "writeOnly" has a value of boolean true, it indicates that the value - is never present when the instance is retrieved from the owning authority. - It can be present when sent to the owning authority to update or create - the document (or the resource it represents), but it will not be included - in any updated or newly created version of the instance. - - - An instance document that is marked as "writeOnly" for the entire document - MAY be returned as a blank document of some sort, or MAY produce an error - upon retrieval, or have the retrieval request ignored, at the authority's - discretion. - - - For example, "readOnly" would be used to mark a database-generated serial - number as read-only, while "writeOnly" would be used to mark a password - input field. - - - These keywords can be used to assist in user interface instance generation. - In particular, an application MAY choose to use a widget that hides - input values as they are typed for write-only fields. - - - Omitting these keywords has the same behavior as values of false. - -
- -
- - The value of this keyword MUST be an array. - There are no restrictions placed on the values within the array. - When multiple occurrences of this keyword are applicable to a single - sub-instance, implementations MUST provide a flat array of all - values rather than an array of arrays. - - - This keyword can be used to provide sample JSON values associated with a - particular schema, for the purpose of illustrating usage. It is - RECOMMENDED that these values be valid against the associated schema. - - - Implementations MAY use the value(s) of "default", if present, as - an additional example. If "examples" is absent, "default" - MAY still be used in this manner. - -
-
- -
- - JSON Schema validation defines a vocabulary for JSON Schema core and concerns all - the security considerations listed there. - - - JSON Schema validation allows the use of Regular Expressions, which have numerous - different (often incompatible) implementations. - Some implementations allow the embedding of arbitrary code, which is outside the - scope of JSON Schema and MUST NOT be permitted. - Regular expressions can often also be crafted to be extremely expensive to compute - (with so-called "catastrophic backtracking"), resulting in a denial-of-service - attack. - - - Implementations that support validating or otherwise evaluating instance - string data based on "contentEncoding" and/or "contentMediaType" are at - risk of evaluating data in an unsafe way based on misleading information. - Applications can mitigate this risk by only performing such processing - when a relationship between the schema and instance is established - (e.g., they share the same authority). - - - Processing a media type or encoding is subject to the security considerations - of that media type or encoding. For example, the security considerations - of RFC 4329 Scripting Media Types apply when - processing JavaScript or ECMAScript encoded within a JSON string. - -
- - - - - - - - &RFC2119; - &RFC1123; - &RFC2045; - &RFC2046; - &RFC2673; - &RFC3339; - &RFC3986; - &RFC3987; - &RFC4122; - &RFC4291; - &RFC4648; - &RFC5321; - &RFC5890; - &RFC5891; - &RFC6570; - &RFC6531; - &RFC6901; - &RFC8259; - - - ECMA-262, 11th edition specification - - - - - - - Relative JSON Pointers - - - - - Cloudflare, Inc. - - - - - - - - - - JSON Schema: A Media Type for Describing JSON Documents - - - - - - - - - - - - - - - - - - - - &RFC4329; - - -
- - Several keywords have been moved from this document into the - Core Specification starting with draft 2019-09, - in some cases with re-naming or other changes. This affects the following former - validation keywords: - - - Renamed to "$defs" to match "$ref" and be shorter to type. - Schema vocabulary authors SHOULD NOT define a "definitions" keyword - with different behavior in order to avoid invalidating schemas that - still use the older name. While "definitions" is absent in the - single-vocabulary meta-schemas referenced by this document, it - remains present in the default meta-schema, and implementations - SHOULD assume that "$defs" and "definitions" have the same - behavior when that meta-schema is used. - - - All of these keywords apply subschemas to the instance and combine - their results, without asserting any conditions of their own. - Without assertion keywords, these applicators can only cause assertion - failures by using the false boolean schema, or by inverting the result - of the true boolean schema (or equivalent schema objects). - For this reason, they are better defined as a generic mechanism on which - validation, hyper-schema, and extension vocabularies can all be based. - - - These keywords modify the behavior of "contains", and are therefore - grouped with it in the applicator vocabulary. - - - This keyword had two different modes of behavior, which made it - relatively challenging to implement and reason about. - The schema form has been moved to Core and renamed to - "dependentSchemas", as part of the applicator vocabulary. - It is analogous to "properties", except that instead of applying - its subschema to the property value, it applies it to the object - containing the property. - The property name array form is retained here and renamed to - "dependentRequired", as it is an assertion which is a shortcut - for the conditional use of the "required" assertion keyword. - - - -
- -
- - Thanks to - Gary Court, - Francis Galiegue, - Kris Zyp, - Geraint Luff, - and Henry Andrews - for their work on the initial drafts of JSON Schema. - - - Thanks to - Jason Desrosiers, - Daniel Perrett, - Erik Wilde, - Evgeny Poberezkin, - Brad Bowman, - Gowry Sankar, - Donald Pipowitch, - Dave Finlay, - Denis Laxalde, - Phil Sturgeon, - Shawn Silverman, - and Karen Etheridge - for their submissions and patches to the document. - -
- -
- - This section to be removed before leaving Internet-Draft status. - - - - - - Use IRIs instead of URIs - - - - - Improve and clarify the "minContains" keyword explanation - Remove the use of "production" in favour of "ABNF rule" - - - - - Correct email format RFC reference to 5321 instead of 5322 - Clarified the set and meaning of "contentEncoding" values - Reference ECMA-262, 11th edition for regular expression support - Split "format" into an annotation only vocabulary and an assertion vocabulary - Clarify "deprecated" when applicable to arrays - - - - - Grouped keywords into formal vocabularies - Update "format" implementation requirements in terms of vocabularies - By default, "format" MUST NOT be validated, although validation can be enabled - A vocabulary declaration can be used to require "format" validation - Moved "definitions" to the core spec as "$defs" - Moved applicator keywords to the core spec - Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec - Specified all "content*" keywords as annotations, not assertions - Added "contentSchema" to allow applying a schema to a string-encoded document - Also allow RFC 4648 encodings in "contentEncoding" - Added "minContains" and "maxContains" - Update RFC reference for "hostname" and "idn-hostname" - Add "uuid" and "duration" formats - - - - - This draft is purely a clarification with no functional changes - Provided the general principle behind ignoring annotations under "not" and similar cases - Clarified "if"/"then"/"else" validation interactions - Clarified "if"/"then"/"else" behavior for annotation - Minor formatting and cross-referencing improvements - - - - - Added "if"/"then"/"else" - Classify keywords as assertions or annotations per the core spec - Warn of possibly removing "dependencies" in the future - Grouped validation keywords into sub-sections for readability - Moved "readOnly" from hyper-schema to validation meta-data - Added "writeOnly" - Added string-encoded media section, with former hyper-schema "media" keywords - Restored "regex" format (removal was unintentional) - Added "date" and "time" formats, and reserved additional RFC 3339 format names - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" - Clarify that "json-pointer" format means string encoding, not URI fragment - Fixed typo that inverted the meaning of "minimum" and "exclusiveMinimum" - Move format syntax references into Normative References - JSON is a normative requirement - - - - - Standardized on hyphenated format names with full words ("uriref" becomes "uri-reference") - Add the formats "uri-template" and "json-pointer" - Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean modifiers of "maximum"/"minimum" to independent numeric fields. - Split the additionalItems/items into two sections - Reworked properties/patternProperties/additionalProperties definition - Added "examples" keyword - Added "contains" keyword - Allow empty "required" and "dependencies" arrays - Fixed "type" reference to primitive types - Added "const" keyword - Added "propertyNames" keyword - - - - - Added additional security considerations - Removed reference to "latest version" meta-schema, use numbered version instead - Rephrased many keyword definitions for brevity - Added "uriref" format that also allows relative URI references - - - - - Initial draft. - Salvaged from draft v3. - Redefine the "required" keyword. - Remove "extends", "disallow" - Add "anyOf", "allOf", "oneOf", "not", "definitions", "minProperties", - "maxProperties". - "dependencies" member values can no longer be single strings; at - least one element is required in a property dependency array. - Rename "divisibleBy" to "multipleOf". - "type" arrays can no longer have schemas; remove "any" as a possible - value. - Rework the "format" section; make support optional. - "format": remove attributes "phone", "style", "color"; rename - "ip-address" to "ipv4"; add references for all attributes. - Provide algorithms to calculate schema(s) for array/object - instances. - Add interoperability considerations. - - - - -
- - diff --git a/package-lock.json b/package-lock.json new file mode 100644 index 00000000..0f9b1984 --- /dev/null +++ b/package-lock.json @@ -0,0 +1,7606 @@ +{ + "name": "@json-schema-org/json-schema-spec", + "version": "1.0.0", + "lockfileVersion": 3, + "requires": true, + "packages": { + "": { + "name": "@json-schema-org/json-schema-spec", + "version": "1.0.0", + "license": "MIT", + "dependencies": { + "mdast-builder": "^1.1.1", + "mdast-util-find-and-replace": "^3.0.0", + "mdast-util-to-string": "^4.0.0", + "rehype-stringify": "^9.0.3", + "remark": "^14.0.3", + "remark-flexible-containers": "^1.0.6", + "remark-gfm": "^3.0.1", + "remark-heading-id": "^1.0.0", + "remark-preset-lint-markdown-style-guide": "^5.1.3", + "remark-rehype": "^10.1.0", + "remark-torchlight": "^0.0.5", + "remark-validate-links": "^12.1.1", + "unist-builder": "^4.0.0", + "vfile-reporter": "^8.0.0" + }, + "devDependencies": { + "dotenv": "^16.3.1", + "eslint": "^8.47.0", + "eslint-import-resolver-node": "^0.3.9", + "eslint-plugin-import": "^2.28.0" + } + }, + "node_modules/@aashutoshrathi/word-wrap": { + "version": "1.2.6", + "resolved": "https://registry.npmjs.org/@aashutoshrathi/word-wrap/-/word-wrap-1.2.6.tgz", + "integrity": "sha512-1Yjs2SvM8TflER/OD3cOjhWWOZb58A2t7wpE2S9XfBYTiIl+XFhQG2bjy4Pu1I+EAlCNUzRDYDdFwFYUKvXcIA==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/@babel/code-frame": { + "version": "7.22.10", + "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.22.10.tgz", + "integrity": "sha512-/KKIMG4UEL35WmI9OlvMhurwtytjvXoFcGNrOvyG9zIzA8YmPjVtIZUf7b05+TPO7G7/GEmLHDaoCgACHl9hhA==", + "dependencies": { + "@babel/highlight": "^7.22.10", + "chalk": "^2.4.2" + }, + "engines": { + "node": ">=6.9.0" + } + }, + "node_modules/@babel/code-frame/node_modules/ansi-styles": { + "version": "3.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", + "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", + "dependencies": { + "color-convert": "^1.9.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/code-frame/node_modules/chalk": { + "version": "2.4.2", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", + "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", + "dependencies": { + "ansi-styles": "^3.2.1", + "escape-string-regexp": "^1.0.5", + "supports-color": "^5.3.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/code-frame/node_modules/color-convert": { + "version": "1.9.3", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", + "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", + "dependencies": { + "color-name": "1.1.3" + } + }, + "node_modules/@babel/code-frame/node_modules/color-name": { + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", + "integrity": "sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==" + }, + "node_modules/@babel/code-frame/node_modules/escape-string-regexp": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", + "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/@babel/code-frame/node_modules/has-flag": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", + "integrity": "sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==", + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/code-frame/node_modules/supports-color": { + "version": "5.5.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", + "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", + "dependencies": { + "has-flag": "^3.0.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/helper-validator-identifier": { + "version": "7.22.5", + "resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.22.5.tgz", + "integrity": "sha512-aJXu+6lErq8ltp+JhkJUfk1MTGyuA4v7f3pA+BJ5HLfNC6nAQ0Cpi9uOquUj8Hehg0aUiHzWQbOVJGao6ztBAQ==", + "engines": { + "node": ">=6.9.0" + } + }, + "node_modules/@babel/highlight": { + "version": "7.22.10", + "resolved": "https://registry.npmjs.org/@babel/highlight/-/highlight-7.22.10.tgz", + "integrity": "sha512-78aUtVcT7MUscr0K5mIEnkwxPE0MaxkR5RxRwuHaQ+JuU5AmTPhY+do2mdzVTnIJJpyBglql2pehuBIWHug+WQ==", + "dependencies": { + "@babel/helper-validator-identifier": "^7.22.5", + "chalk": "^2.4.2", + "js-tokens": "^4.0.0" + }, + "engines": { + "node": ">=6.9.0" + } + }, + "node_modules/@babel/highlight/node_modules/ansi-styles": { + "version": "3.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", + "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", + "dependencies": { + "color-convert": "^1.9.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/highlight/node_modules/chalk": { + "version": "2.4.2", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", + "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", + "dependencies": { + "ansi-styles": "^3.2.1", + "escape-string-regexp": "^1.0.5", + "supports-color": "^5.3.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/highlight/node_modules/color-convert": { + "version": "1.9.3", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", + "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", + "dependencies": { + "color-name": "1.1.3" + } + }, + "node_modules/@babel/highlight/node_modules/color-name": { + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", + "integrity": "sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==" + }, + "node_modules/@babel/highlight/node_modules/escape-string-regexp": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", + "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/@babel/highlight/node_modules/has-flag": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", + "integrity": "sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==", + "engines": { + "node": ">=4" + } + }, + "node_modules/@babel/highlight/node_modules/supports-color": { + "version": "5.5.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", + "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", + "dependencies": { + "has-flag": "^3.0.0" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/@eslint-community/eslint-utils": { + "version": "4.4.0", + "resolved": "https://registry.npmjs.org/@eslint-community/eslint-utils/-/eslint-utils-4.4.0.tgz", + "integrity": "sha512-1/sA4dwrzBAyeUoQ6oxahHKmrZvsnLCg4RfxW3ZFGGmQkSNQPFNLV9CUEFQP1x9EYXHTo5p6xdhZM1Ne9p/AfA==", + "dev": true, + "dependencies": { + "eslint-visitor-keys": "^3.3.0" + }, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "peerDependencies": { + "eslint": "^6.0.0 || ^7.0.0 || >=8.0.0" + } + }, + "node_modules/@eslint-community/regexpp": { + "version": "4.6.2", + "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.6.2.tgz", + "integrity": "sha512-pPTNuaAG3QMH+buKyBIGJs3g/S5y0caxw0ygM3YyE6yJFySwiGGSzA+mM3KJ8QQvzeLh3blwgSonkFjgQdxzMw==", + "dev": true, + "engines": { + "node": "^12.0.0 || ^14.0.0 || >=16.0.0" + } + }, + "node_modules/@eslint/eslintrc": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-2.1.2.tgz", + "integrity": "sha512-+wvgpDsrB1YqAMdEUCcnTlpfVBH7Vqn6A/NT3D8WVXFIaKMlErPIZT3oCIAVCOtarRpMtelZLqJeU3t7WY6X6g==", + "dev": true, + "dependencies": { + "ajv": "^6.12.4", + "debug": "^4.3.2", + "espree": "^9.6.0", + "globals": "^13.19.0", + "ignore": "^5.2.0", + "import-fresh": "^3.2.1", + "js-yaml": "^4.1.0", + "minimatch": "^3.1.2", + "strip-json-comments": "^3.1.1" + }, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "funding": { + "url": "https://opencollective.com/eslint" + } + }, + "node_modules/@eslint/js": { + "version": "8.47.0", + "resolved": "https://registry.npmjs.org/@eslint/js/-/js-8.47.0.tgz", + "integrity": "sha512-P6omY1zv5MItm93kLM8s2vr1HICJH8v0dvddDhysbIuZ+vcjOHg5Zbkf1mTkcmi2JA9oBG2anOkRnW8WJTS8Og==", + "dev": true, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + } + }, + "node_modules/@humanwhocodes/config-array": { + "version": "0.11.10", + "resolved": "https://registry.npmjs.org/@humanwhocodes/config-array/-/config-array-0.11.10.tgz", + "integrity": "sha512-KVVjQmNUepDVGXNuoRRdmmEjruj0KfiGSbS8LVc12LMsWDQzRXJ0qdhN8L8uUigKpfEHRhlaQFY0ib1tnUbNeQ==", + "dev": true, + "dependencies": { + "@humanwhocodes/object-schema": "^1.2.1", + "debug": "^4.1.1", + "minimatch": "^3.0.5" + }, + "engines": { + "node": ">=10.10.0" + } + }, + "node_modules/@humanwhocodes/module-importer": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/@humanwhocodes/module-importer/-/module-importer-1.0.1.tgz", + "integrity": "sha512-bxveV4V8v5Yb4ncFTT3rPSgZBOpCkjfK0y4oVVVJwIuDVBRMDXrPyXRL988i5ap9m9bnyEEjWfm5WkBmtffLfA==", + "dev": true, + "engines": { + "node": ">=12.22" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/nzakas" + } + }, + "node_modules/@humanwhocodes/object-schema": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/@humanwhocodes/object-schema/-/object-schema-1.2.1.tgz", + "integrity": "sha512-ZnQMnLV4e7hDlUvw8H+U8ASL02SS2Gn6+9Ac3wGGLIe7+je2AeAOxPY+izIPJDfFDb7eDjev0Us8MO1iFRN8hA==", + "dev": true + }, + "node_modules/@isaacs/cliui": { + "version": "8.0.2", + "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz", + "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==", + "dependencies": { + "string-width": "^5.1.2", + "string-width-cjs": "npm:string-width@^4.2.0", + "strip-ansi": "^7.0.1", + "strip-ansi-cjs": "npm:strip-ansi@^6.0.1", + "wrap-ansi": "^8.1.0", + "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0" + }, + "engines": { + "node": ">=12" + } + }, + "node_modules/@isaacs/cliui/node_modules/ansi-regex": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz", + "integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-regex?sponsor=1" + } + }, + "node_modules/@isaacs/cliui/node_modules/ansi-styles": { + "version": "6.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", + "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-styles?sponsor=1" + } + }, + "node_modules/@isaacs/cliui/node_modules/emoji-regex": { + "version": "9.2.2", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", + "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==" + }, + "node_modules/@isaacs/cliui/node_modules/string-width": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", + "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", + "dependencies": { + "eastasianwidth": "^0.2.0", + "emoji-regex": "^9.2.2", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/@isaacs/cliui/node_modules/strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dependencies": { + "ansi-regex": "^6.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" + } + }, + "node_modules/@isaacs/cliui/node_modules/wrap-ansi": { + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", + "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", + "dependencies": { + "ansi-styles": "^6.1.0", + "string-width": "^5.0.1", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/wrap-ansi?sponsor=1" + } + }, + "node_modules/@nodelib/fs.scandir": { + "version": "2.1.5", + "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz", + "integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==", + "dev": true, + "dependencies": { + "@nodelib/fs.stat": "2.0.5", + "run-parallel": "^1.1.9" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@nodelib/fs.stat": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz", + "integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==", + "dev": true, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@nodelib/fs.walk": { + "version": "1.2.8", + "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz", + "integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==", + "dev": true, + "dependencies": { + "@nodelib/fs.scandir": "2.1.5", + "fastq": "^1.6.0" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/@npmcli/config": { + "version": "6.2.1", + "resolved": "https://registry.npmjs.org/@npmcli/config/-/config-6.2.1.tgz", + "integrity": "sha512-Cj/OrSbrLvnwWuzquFCDTwFN8QmR+SWH6qLNCBttUreDkKM5D5p36SeSMbcEUiCGdwjUrVy2yd8C0REwwwDPEw==", + "dependencies": { + "@npmcli/map-workspaces": "^3.0.2", + "ci-info": "^3.8.0", + "ini": "^4.1.0", + "nopt": "^7.0.0", + "proc-log": "^3.0.0", + "read-package-json-fast": "^3.0.2", + "semver": "^7.3.5", + "walk-up-path": "^3.0.1" + }, + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/@npmcli/config/node_modules/lru-cache": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-6.0.0.tgz", + "integrity": "sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==", + "dependencies": { + "yallist": "^4.0.0" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/@npmcli/config/node_modules/semver": { + "version": "7.5.4", + "resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz", + "integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==", + "dependencies": { + "lru-cache": "^6.0.0" + }, + "bin": { + "semver": "bin/semver.js" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/@npmcli/map-workspaces": { + "version": "3.0.4", + "resolved": "https://registry.npmjs.org/@npmcli/map-workspaces/-/map-workspaces-3.0.4.tgz", + "integrity": "sha512-Z0TbvXkRbacjFFLpVpV0e2mheCh+WzQpcqL+4xp49uNJOxOnIAPZyXtUxZ5Qn3QBTGKA11Exjd9a5411rBrhDg==", + "dependencies": { + "@npmcli/name-from-folder": "^2.0.0", + "glob": "^10.2.2", + "minimatch": "^9.0.0", + "read-package-json-fast": "^3.0.0" + }, + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/@npmcli/map-workspaces/node_modules/brace-expansion": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", + "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dependencies": { + "balanced-match": "^1.0.0" + } + }, + "node_modules/@npmcli/map-workspaces/node_modules/glob": { + "version": "10.3.3", + "resolved": "https://registry.npmjs.org/glob/-/glob-10.3.3.tgz", + "integrity": "sha512-92vPiMb/iqpmEgsOoIDvTjc50wf9CCCvMzsi6W0JLPeUKE8TWP1a73PgqSrqy7iAZxaSD1YdzU7QZR5LF51MJw==", + "dependencies": { + "foreground-child": "^3.1.0", + "jackspeak": "^2.0.3", + "minimatch": "^9.0.1", + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0", + "path-scurry": "^1.10.1" + }, + "bin": { + "glob": "dist/cjs/src/bin.js" + }, + "engines": { + "node": ">=16 || 14 >=14.17" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/@npmcli/map-workspaces/node_modules/minimatch": { + "version": "9.0.3", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.3.tgz", + "integrity": "sha512-RHiac9mvaRw0x3AYRgDC1CxAP7HTcNrrECeA8YYJeWnpo+2Q5CegtZjaotWTWxDG3UeGA1coE05iH1mPjT/2mg==", + "dependencies": { + "brace-expansion": "^2.0.1" + }, + "engines": { + "node": ">=16 || 14 >=14.17" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/@npmcli/name-from-folder": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/@npmcli/name-from-folder/-/name-from-folder-2.0.0.tgz", + "integrity": "sha512-pwK+BfEBZJbKdNYpHHRTNBwBoqrN/iIMO0AiGvYsp3Hoaq0WbgGSWQR6SCldZovoDpY3yje5lkFUe6gsDgJ2vg==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/@pkgjs/parseargs": { + "version": "0.11.0", + "resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz", + "integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==", + "optional": true, + "engines": { + "node": ">=14" + } + }, + "node_modules/@torchlight-api/torchlight-cli": { + "version": "0.1.7", + "resolved": "https://registry.npmjs.org/@torchlight-api/torchlight-cli/-/torchlight-cli-0.1.7.tgz", + "integrity": "sha512-sHph49Nx/VfzwDsb43v6AQIDZQa/YQ1LtGKTmN/rEBJoW0ctMXUQUJ1c75rNQ/1n2rYLbQLf7s008/jgLvkEDg==", + "dependencies": { + "axios": "^0.21.1", + "chalk": "^4.1.2", + "cheerio": "^1.0.0-rc.10", + "chokidar": "^3.5.2", + "commander": "^8.1.0", + "fs-extra": "^10.0.0", + "inquirer": "^8.1.2", + "lodash.chunk": "^4.2.0", + "lodash.get": "^4.4.2", + "md5": "^2.3.0" + }, + "bin": { + "torchlight": "dist/bin/torchlight.cjs.js" + } + }, + "node_modules/@types/concat-stream": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/@types/concat-stream/-/concat-stream-2.0.0.tgz", + "integrity": "sha512-t3YCerNM7NTVjLuICZo5gYAXYoDvpuuTceCcFQWcDQz26kxUR5uIWolxbIR5jRNIXpMqhOpW/b8imCR1LEmuJw==", + "dependencies": { + "@types/node": "*" + } + }, + "node_modules/@types/debug": { + "version": "4.1.8", + "resolved": "https://registry.npmjs.org/@types/debug/-/debug-4.1.8.tgz", + "integrity": "sha512-/vPO1EPOs306Cvhwv7KfVfYvOJqA/S/AXjaHQiJboCZzcNDb+TIJFN9/2C9DZ//ijSKWioNyUxD792QmDJ+HKQ==", + "dependencies": { + "@types/ms": "*" + } + }, + "node_modules/@types/estree": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.1.tgz", + "integrity": "sha512-LG4opVs2ANWZ1TJoKc937iMmNstM/d0ae1vNbnBvBhqCSezgVUOzcLCqbI5elV8Vy6WKwKjaqR+zO9VKirBBCA==" + }, + "node_modules/@types/estree-jsx": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/@types/estree-jsx/-/estree-jsx-1.0.0.tgz", + "integrity": "sha512-3qvGd0z8F2ENTGr/GG1yViqfiKmRfrXVx5sJyHGFu3z7m5g5utCQtGp/g29JnjflhtQJBv1WDQukHiT58xPcYQ==", + "dependencies": { + "@types/estree": "*" + } + }, + "node_modules/@types/hast": { + "version": "2.3.5", + "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.5.tgz", + "integrity": "sha512-SvQi0L/lNpThgPoleH53cdjB3y9zpLlVjRbqB3rH8hx1jiRSBGAhyjV3H+URFjNVRqt2EdYNrbZE5IsGlNfpRg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/@types/is-empty": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/@types/is-empty/-/is-empty-1.2.1.tgz", + "integrity": "sha512-a3xgqnFTuNJDm1fjsTjHocYJ40Cz3t8utYpi5GNaxzrJC2HSD08ym+whIL7fNqiqBCdM9bcqD1H/tORWAFXoZw==" + }, + "node_modules/@types/json5": { + "version": "0.0.29", + "resolved": "https://registry.npmjs.org/@types/json5/-/json5-0.0.29.tgz", + "integrity": "sha512-dRLjCWHYg4oaA77cxO64oO+7JwCwnIzkZPdrrC71jQmQtlhM556pwKo5bUzqvZndkVbeFLIIi+9TC40JNF5hNQ==", + "dev": true + }, + "node_modules/@types/mdast": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-4.0.0.tgz", + "integrity": "sha512-YLeG8CujC9adtj/kuDzq1N4tCDYKoZ5l/bnjq8d74+t/3q/tHquJOJKUQXJrLCflOHpKjXgcI/a929gpmLOEng==", + "dependencies": { + "@types/unist": "*" + } + }, + "node_modules/@types/ms": { + "version": "0.7.31", + "resolved": "https://registry.npmjs.org/@types/ms/-/ms-0.7.31.tgz", + "integrity": "sha512-iiUgKzV9AuaEkZqkOLDIvlQiL6ltuZd9tGcW3gwpnX8JbuiuhFlEGmmFXEXkN50Cvq7Os88IY2v0dkDqXYWVgA==" + }, + "node_modules/@types/node": { + "version": "18.17.5", + "resolved": "https://registry.npmjs.org/@types/node/-/node-18.17.5.tgz", + "integrity": "sha512-xNbS75FxH6P4UXTPUJp/zNPq6/xsfdJKussCWNOnz4aULWIRwMgP1LgaB5RiBnMX1DPCYenuqGZfnIAx5mbFLA==" + }, + "node_modules/@types/parse5": { + "version": "6.0.3", + "resolved": "https://registry.npmjs.org/@types/parse5/-/parse5-6.0.3.tgz", + "integrity": "sha512-SuT16Q1K51EAVPz1K29DJ/sXjhSQ0zjvsypYJ6tlwVsRV9jwW5Adq2ch8Dq8kDBCkYnELS7N7VNCSB5nC56t/g==" + }, + "node_modules/@types/supports-color": { + "version": "8.1.1", + "resolved": "https://registry.npmjs.org/@types/supports-color/-/supports-color-8.1.1.tgz", + "integrity": "sha512-dPWnWsf+kzIG140B8z2w3fr5D03TLWbOAFQl45xUpI3vcizeXriNR5VYkWZ+WTMsUHqZ9Xlt3hrxGNANFyNQfw==" + }, + "node_modules/@types/unist": { + "version": "2.0.7", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-2.0.7.tgz", + "integrity": "sha512-cputDpIbFgLUaGQn6Vqg3/YsJwxUwHLO13v3i5ouxT4lat0khip9AEWxtERujXV9wxIB1EyF97BSJFt6vpdI8g==" + }, + "node_modules/abbrev": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-2.0.0.tgz", + "integrity": "sha512-6/mh1E2u2YgEsCHdY0Yx5oW+61gZU+1vXaoiHHrpKeuRNNgFvS+/jrwHiQhB5apAf5oB7UB7E19ol2R2LKH8hQ==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/acorn": { + "version": "8.10.0", + "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.10.0.tgz", + "integrity": "sha512-F0SAmZ8iUtS//m8DmCTA0jlh6TDKkHQyK6xc6V4KDTyZKA9dnvX9/3sRTVQrWm79glUAZbnmmNcdYwUIHWVybw==", + "dev": true, + "bin": { + "acorn": "bin/acorn" + }, + "engines": { + "node": ">=0.4.0" + } + }, + "node_modules/acorn-jsx": { + "version": "5.3.2", + "resolved": "https://registry.npmjs.org/acorn-jsx/-/acorn-jsx-5.3.2.tgz", + "integrity": "sha512-rq9s+JNhf0IChjtDXxllJ7g41oZk5SlXtp0LHwyA5cejwn7vKmKp4pPri6YEePv2PU65sAsegbXtIinmDFDXgQ==", + "dev": true, + "peerDependencies": { + "acorn": "^6.0.0 || ^7.0.0 || ^8.0.0" + } + }, + "node_modules/ajv": { + "version": "6.12.6", + "resolved": "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz", + "integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==", + "dev": true, + "dependencies": { + "fast-deep-equal": "^3.1.1", + "fast-json-stable-stringify": "^2.0.0", + "json-schema-traverse": "^0.4.1", + "uri-js": "^4.2.2" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/epoberezkin" + } + }, + "node_modules/ansi-escapes": { + "version": "4.3.2", + "resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.2.tgz", + "integrity": "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ==", + "dependencies": { + "type-fest": "^0.21.3" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/ansi-escapes/node_modules/type-fest": { + "version": "0.21.3", + "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz", + "integrity": "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w==", + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "engines": { + "node": ">=8" + } + }, + "node_modules/ansi-styles": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", + "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", + "dependencies": { + "color-convert": "^2.0.1" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/chalk/ansi-styles?sponsor=1" + } + }, + "node_modules/anymatch": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz", + "integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==", + "dependencies": { + "normalize-path": "^3.0.0", + "picomatch": "^2.0.4" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/argparse": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", + "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", + "dev": true + }, + "node_modules/array-buffer-byte-length": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/array-buffer-byte-length/-/array-buffer-byte-length-1.0.0.tgz", + "integrity": "sha512-LPuwb2P+NrQw3XhxGc36+XSvuBPopovXYTR9Ew++Du9Yb/bx5AzBfrIsBoj0EZUifjQU+sHL21sseZ3jerWO/A==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "is-array-buffer": "^3.0.1" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/array-includes": { + "version": "3.1.6", + "resolved": "https://registry.npmjs.org/array-includes/-/array-includes-3.1.6.tgz", + "integrity": "sha512-sgTbLvL6cNnw24FnbaDyjmvddQ2ML8arZsgaJhoABMoplz/4QRhtrYS+alr1BUM1Bwp6dhx8vVCBSLG+StwOFw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4", + "get-intrinsic": "^1.1.3", + "is-string": "^1.0.7" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/array.prototype.findlastindex": { + "version": "1.2.2", + "resolved": "https://registry.npmjs.org/array.prototype.findlastindex/-/array.prototype.findlastindex-1.2.2.tgz", + "integrity": "sha512-tb5thFFlUcp7NdNF6/MpDk/1r/4awWG1FIz3YqDf+/zJSTezBb+/5WViH41obXULHVpDzoiCLpJ/ZO9YbJMsdw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4", + "es-shim-unscopables": "^1.0.0", + "get-intrinsic": "^1.1.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/array.prototype.flat": { + "version": "1.3.1", + "resolved": "https://registry.npmjs.org/array.prototype.flat/-/array.prototype.flat-1.3.1.tgz", + "integrity": "sha512-roTU0KWIOmJ4DRLmwKd19Otg0/mT3qPNt0Qb3GWW8iObuZXxrjB/pzn0R3hqpRSWg4HCwqx+0vwOnWnvlOyeIA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4", + "es-shim-unscopables": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/array.prototype.flatmap": { + "version": "1.3.1", + "resolved": "https://registry.npmjs.org/array.prototype.flatmap/-/array.prototype.flatmap-1.3.1.tgz", + "integrity": "sha512-8UGn9O1FDVvMNB0UlLv4voxRMze7+FpHyF5mSMRjWHUMlpoDViniy05870VlxhfgTnLbpuwTzvD76MTtWxB/mQ==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4", + "es-shim-unscopables": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/arraybuffer.prototype.slice": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/arraybuffer.prototype.slice/-/arraybuffer.prototype.slice-1.0.1.tgz", + "integrity": "sha512-09x0ZWFEjj4WD8PDbykUwo3t9arLn8NIzmmYEJFpYekOAQjpkGSyrQhNoRTcwwcFRu+ycWF78QZ63oWTqSjBcw==", + "dev": true, + "dependencies": { + "array-buffer-byte-length": "^1.0.0", + "call-bind": "^1.0.2", + "define-properties": "^1.2.0", + "get-intrinsic": "^1.2.1", + "is-array-buffer": "^3.0.2", + "is-shared-array-buffer": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/available-typed-arrays": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/available-typed-arrays/-/available-typed-arrays-1.0.5.tgz", + "integrity": "sha512-DMD0KiN46eipeziST1LPP/STfDU0sufISXmjSgvVsoU2tqxctQeASejWcfNtxYKqETM1UxQ8sp2OrSBWpHY6sw==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/axios": { + "version": "0.21.4", + "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.4.tgz", + "integrity": "sha512-ut5vewkiu8jjGBdqpM44XxjuCjq9LAKeHVmoVfHVzy8eHgxxq8SbAVQNovDA8mVi05kP0Ea/n/UzcSHcTJQfNg==", + "dependencies": { + "follow-redirects": "^1.14.0" + } + }, + "node_modules/bail": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/bail/-/bail-2.0.2.tgz", + "integrity": "sha512-0xO6mYd7JB2YesxDKplafRpsiOzPt9V02ddPCLbY1xYGPOX24NTyN50qnUxgCPcSoYMhKpAuBTjQoRZCAkUDRw==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/balanced-match": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", + "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==" + }, + "node_modules/base64-js": { + "version": "1.5.1", + "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz", + "integrity": "sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/binary-extensions": { + "version": "2.2.0", + "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.2.0.tgz", + "integrity": "sha512-jDctJ/IVQbZoJykoeHbhXpOlNBqGNcwXJKJog42E5HDPUwQTSdjCHdihjj0DlnheQ7blbT6dHOafNAiS8ooQKA==", + "engines": { + "node": ">=8" + } + }, + "node_modules/bl": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/bl/-/bl-4.1.0.tgz", + "integrity": "sha512-1W07cM9gS6DcLperZfFSj+bWLtaPGSOHWhPiGzXmvVJbRLdG82sH/Kn8EtW1VqWVA54AKf2h5k5BbnIbwF3h6w==", + "dependencies": { + "buffer": "^5.5.0", + "inherits": "^2.0.4", + "readable-stream": "^3.4.0" + } + }, + "node_modules/boolbase": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz", + "integrity": "sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==" + }, + "node_modules/brace-expansion": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", + "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, + "dependencies": { + "balanced-match": "^1.0.0", + "concat-map": "0.0.1" + } + }, + "node_modules/braces": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz", + "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==", + "dependencies": { + "fill-range": "^7.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/buffer": { + "version": "5.7.1", + "resolved": "https://registry.npmjs.org/buffer/-/buffer-5.7.1.tgz", + "integrity": "sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "dependencies": { + "base64-js": "^1.3.1", + "ieee754": "^1.1.13" + } + }, + "node_modules/buffer-from": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", + "integrity": "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==" + }, + "node_modules/call-bind": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.2.tgz", + "integrity": "sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==", + "dev": true, + "dependencies": { + "function-bind": "^1.1.1", + "get-intrinsic": "^1.0.2" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/callsites": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/callsites/-/callsites-3.1.0.tgz", + "integrity": "sha512-P8BjAsXvZS+VIDUI11hHCQEv74YT67YUi5JJFNWIqL235sBmjX4+qx9Muvls5ivyNENctx46xQLQ3aTuE7ssaQ==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/ccount": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/ccount/-/ccount-2.0.1.tgz", + "integrity": "sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/chalk": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz", + "integrity": "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==", + "dependencies": { + "ansi-styles": "^4.1.0", + "supports-color": "^7.1.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/chalk/chalk?sponsor=1" + } + }, + "node_modules/character-entities": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/character-entities/-/character-entities-2.0.2.tgz", + "integrity": "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/character-entities-html4": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/character-entities-html4/-/character-entities-html4-2.1.0.tgz", + "integrity": "sha512-1v7fgQRj6hnSwFpq1Eu0ynr/CDEw0rXo2B61qXrLNdHZmPKgb7fqS1a2JwF0rISo9q77jDI8VMEHoApn8qDoZA==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/character-entities-legacy": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/character-entities-legacy/-/character-entities-legacy-3.0.0.tgz", + "integrity": "sha512-RpPp0asT/6ufRm//AJVwpViZbGM/MkjQFxJccQRHmISF/22NBtsHqAWmL+/pmkPWoIUJdWyeVleTl1wydHATVQ==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/chardet": { + "version": "0.7.0", + "resolved": "https://registry.npmjs.org/chardet/-/chardet-0.7.0.tgz", + "integrity": "sha512-mT8iDcrh03qDGRRmoA2hmBJnxpllMR+0/0qlzjqZES6NdiWDcZkCNAk4rPFZ9Q85r27unkiNNg8ZOiwZXBHwcA==" + }, + "node_modules/charenc": { + "version": "0.0.2", + "resolved": "https://registry.npmjs.org/charenc/-/charenc-0.0.2.tgz", + "integrity": "sha512-yrLQ/yVUFXkzg7EDQsPieE/53+0RlaWTs+wBrvW36cyilJ2SaDWfl4Yj7MtLTXleV9uEKefbAGUPv2/iWSooRA==", + "engines": { + "node": "*" + } + }, + "node_modules/cheerio": { + "version": "1.0.0-rc.12", + "resolved": "https://registry.npmjs.org/cheerio/-/cheerio-1.0.0-rc.12.tgz", + "integrity": "sha512-VqR8m68vM46BNnuZ5NtnGBKIE/DfN0cRIzg9n40EIq9NOv90ayxLBXA8fXC5gquFRGJSTRqBq25Jt2ECLR431Q==", + "dependencies": { + "cheerio-select": "^2.1.0", + "dom-serializer": "^2.0.0", + "domhandler": "^5.0.3", + "domutils": "^3.0.1", + "htmlparser2": "^8.0.1", + "parse5": "^7.0.0", + "parse5-htmlparser2-tree-adapter": "^7.0.0" + }, + "engines": { + "node": ">= 6" + }, + "funding": { + "url": "https://github.com/cheeriojs/cheerio?sponsor=1" + } + }, + "node_modules/cheerio-select": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/cheerio-select/-/cheerio-select-2.1.0.tgz", + "integrity": "sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==", + "dependencies": { + "boolbase": "^1.0.0", + "css-select": "^5.1.0", + "css-what": "^6.1.0", + "domelementtype": "^2.3.0", + "domhandler": "^5.0.3", + "domutils": "^3.0.1" + }, + "funding": { + "url": "https://github.com/sponsors/fb55" + } + }, + "node_modules/cheerio/node_modules/parse5": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.1.2.tgz", + "integrity": "sha512-Czj1WaSVpaoj0wbhMzLmWD69anp2WH7FXMB9n1Sy8/ZFF9jolSQVMu1Ij5WIyGmcBmhk7EOndpO4mIpihVqAXw==", + "dependencies": { + "entities": "^4.4.0" + }, + "funding": { + "url": "https://github.com/inikulin/parse5?sponsor=1" + } + }, + "node_modules/chokidar": { + "version": "3.5.3", + "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.5.3.tgz", + "integrity": "sha512-Dr3sfKRP6oTcjf2JmUmFJfeVMvXBdegxB0iVQ5eb2V10uFJUCAS8OByZdVAyVb8xXNz3GjjTgj9kLWsZTqE6kw==", + "funding": [ + { + "type": "individual", + "url": "https://paulmillr.com/funding/" + } + ], + "dependencies": { + "anymatch": "~3.1.2", + "braces": "~3.0.2", + "glob-parent": "~5.1.2", + "is-binary-path": "~2.1.0", + "is-glob": "~4.0.1", + "normalize-path": "~3.0.0", + "readdirp": "~3.6.0" + }, + "engines": { + "node": ">= 8.10.0" + }, + "optionalDependencies": { + "fsevents": "~2.3.2" + } + }, + "node_modules/chokidar/node_modules/glob-parent": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", + "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", + "dependencies": { + "is-glob": "^4.0.1" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/ci-info": { + "version": "3.8.0", + "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-3.8.0.tgz", + "integrity": "sha512-eXTggHWSooYhq49F2opQhuHWgzucfF2YgODK4e1566GQs5BIfP30B0oenwBJHfWxAs2fyPB1s7Mg949zLf61Yw==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/sibiraj-s" + } + ], + "engines": { + "node": ">=8" + } + }, + "node_modules/cli-cursor": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/cli-cursor/-/cli-cursor-3.1.0.tgz", + "integrity": "sha512-I/zHAwsKf9FqGoXM4WWRACob9+SNukZTd94DWF57E4toouRulbCxcUh6RKUEOQlYTHJnzkPMySvPNaaSLNfLZw==", + "dependencies": { + "restore-cursor": "^3.1.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/cli-spinners": { + "version": "2.9.0", + "resolved": "https://registry.npmjs.org/cli-spinners/-/cli-spinners-2.9.0.tgz", + "integrity": "sha512-4/aL9X3Wh0yiMQlE+eeRhWP6vclO3QRtw1JHKIT0FFUs5FjpFmESqtMvYZ0+lbzBw900b95mS0hohy+qn2VK/g==", + "engines": { + "node": ">=6" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/cli-width": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/cli-width/-/cli-width-3.0.0.tgz", + "integrity": "sha512-FxqpkPPwu1HjuN93Omfm4h8uIanXofW0RxVEW3k5RKx+mJJYSthzNhp32Kzxxy3YAEZ/Dc/EWN1vZRY0+kOhbw==", + "engines": { + "node": ">= 10" + } + }, + "node_modules/clone": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/clone/-/clone-1.0.4.tgz", + "integrity": "sha512-JQHZ2QMW6l3aH/j6xCqQThY/9OH4D/9ls34cgkUBiEeocRTU04tHfKPBsUK1PqZCUQM7GiA0IIXJSuXHI64Kbg==", + "engines": { + "node": ">=0.8" + } + }, + "node_modules/color-convert": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", + "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dependencies": { + "color-name": "~1.1.4" + }, + "engines": { + "node": ">=7.0.0" + } + }, + "node_modules/color-name": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", + "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==" + }, + "node_modules/comma-separated-tokens": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/comma-separated-tokens/-/comma-separated-tokens-2.0.3.tgz", + "integrity": "sha512-Fu4hJdvzeylCfQPp9SGWidpzrMs7tTrlu6Vb8XGaRGck8QSNZJJp538Wrb60Lax4fPwR64ViY468OIUTbRlGZg==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/commander": { + "version": "8.3.0", + "resolved": "https://registry.npmjs.org/commander/-/commander-8.3.0.tgz", + "integrity": "sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==", + "engines": { + "node": ">= 12" + } + }, + "node_modules/concat-map": { + "version": "0.0.1", + "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz", + "integrity": "sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==", + "dev": true + }, + "node_modules/concat-stream": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/concat-stream/-/concat-stream-2.0.0.tgz", + "integrity": "sha512-MWufYdFw53ccGjCA+Ol7XJYpAlW6/prSMzuPOTRnJGcGzuhLn4Scrz7qf6o8bROZ514ltazcIFJZevcfbo0x7A==", + "engines": [ + "node >= 6.0" + ], + "dependencies": { + "buffer-from": "^1.0.0", + "inherits": "^2.0.3", + "readable-stream": "^3.0.2", + "typedarray": "^0.0.6" + } + }, + "node_modules/cross-spawn": { + "version": "7.0.3", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz", + "integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==", + "dependencies": { + "path-key": "^3.1.0", + "shebang-command": "^2.0.0", + "which": "^2.0.1" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/crypt": { + "version": "0.0.2", + "resolved": "https://registry.npmjs.org/crypt/-/crypt-0.0.2.tgz", + "integrity": "sha512-mCxBlsHFYh9C+HVpiEacem8FEBnMXgU9gy4zmNC+SXAZNB/1idgp/aulFJ4FgCi7GPEVbfyng092GqL2k2rmow==", + "engines": { + "node": "*" + } + }, + "node_modules/css-select": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/css-select/-/css-select-5.1.0.tgz", + "integrity": "sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==", + "dependencies": { + "boolbase": "^1.0.0", + "css-what": "^6.1.0", + "domhandler": "^5.0.2", + "domutils": "^3.0.1", + "nth-check": "^2.0.1" + }, + "funding": { + "url": "https://github.com/sponsors/fb55" + } + }, + "node_modules/css-what": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/css-what/-/css-what-6.1.0.tgz", + "integrity": "sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==", + "engines": { + "node": ">= 6" + }, + "funding": { + "url": "https://github.com/sponsors/fb55" + } + }, + "node_modules/debug": { + "version": "4.3.4", + "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.4.tgz", + "integrity": "sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==", + "dependencies": { + "ms": "2.1.2" + }, + "engines": { + "node": ">=6.0" + }, + "peerDependenciesMeta": { + "supports-color": { + "optional": true + } + } + }, + "node_modules/decode-named-character-reference": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.0.2.tgz", + "integrity": "sha512-O8x12RzrUF8xyVcY0KJowWsmaJxQbmy0/EtnNtHRpsOcT7dFk5W598coHqBVpmWo1oQQfsCqfCmkZN5DJrZVdg==", + "dependencies": { + "character-entities": "^2.0.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/deep-is": { + "version": "0.1.4", + "resolved": "https://registry.npmjs.org/deep-is/-/deep-is-0.1.4.tgz", + "integrity": "sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==", + "dev": true + }, + "node_modules/defaults": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/defaults/-/defaults-1.0.4.tgz", + "integrity": "sha512-eFuaLoy/Rxalv2kr+lqMlUnrDWV+3j4pljOIJgLIhI058IQfWJ7vXhyEIHu+HtC738klGALYxOKDO0bQP3tg8A==", + "dependencies": { + "clone": "^1.0.2" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/define-properties": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/define-properties/-/define-properties-1.2.0.tgz", + "integrity": "sha512-xvqAVKGfT1+UAvPwKTVw/njhdQ8ZhXK4lI0bCIuCMrp2up9nPnaDftrLtmpTazqd1o+UY4zgzU+avtMbDP+ldA==", + "dev": true, + "dependencies": { + "has-property-descriptors": "^1.0.0", + "object-keys": "^1.1.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/dequal": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/dequal/-/dequal-2.0.3.tgz", + "integrity": "sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==", + "engines": { + "node": ">=6" + } + }, + "node_modules/diff": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/diff/-/diff-5.1.0.tgz", + "integrity": "sha512-D+mk+qE8VC/PAUrlAU34N+VfXev0ghe5ywmpqrawphmVZc1bEfn56uo9qpyGp1p4xpzOHkSW4ztBd6L7Xx4ACw==", + "engines": { + "node": ">=0.3.1" + } + }, + "node_modules/doctrine": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/doctrine/-/doctrine-3.0.0.tgz", + "integrity": "sha512-yS+Q5i3hBf7GBkd4KG8a7eBNNWNGLTaEwwYWUijIYM7zrlYDM0BFXHjjPWlWZ1Rg7UaddZeIDmi9jF3HmqiQ2w==", + "dev": true, + "dependencies": { + "esutils": "^2.0.2" + }, + "engines": { + "node": ">=6.0.0" + } + }, + "node_modules/dom-serializer": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-2.0.0.tgz", + "integrity": "sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==", + "dependencies": { + "domelementtype": "^2.3.0", + "domhandler": "^5.0.2", + "entities": "^4.2.0" + }, + "funding": { + "url": "https://github.com/cheeriojs/dom-serializer?sponsor=1" + } + }, + "node_modules/domelementtype": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.3.0.tgz", + "integrity": "sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/fb55" + } + ] + }, + "node_modules/domhandler": { + "version": "5.0.3", + "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz", + "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==", + "dependencies": { + "domelementtype": "^2.3.0" + }, + "engines": { + "node": ">= 4" + }, + "funding": { + "url": "https://github.com/fb55/domhandler?sponsor=1" + } + }, + "node_modules/domutils": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/domutils/-/domutils-3.1.0.tgz", + "integrity": "sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==", + "dependencies": { + "dom-serializer": "^2.0.0", + "domelementtype": "^2.3.0", + "domhandler": "^5.0.3" + }, + "funding": { + "url": "https://github.com/fb55/domutils?sponsor=1" + } + }, + "node_modules/dotenv": { + "version": "16.3.1", + "resolved": "https://registry.npmjs.org/dotenv/-/dotenv-16.3.1.tgz", + "integrity": "sha512-IPzF4w4/Rd94bA9imS68tZBaYyBWSCE47V1RGuMrB94iyTOIEwRmVL2x/4An+6mETpLrKJ5hQkB8W4kFAadeIQ==", + "dev": true, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/motdotla/dotenv?sponsor=1" + } + }, + "node_modules/eastasianwidth": { + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz", + "integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==" + }, + "node_modules/emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==" + }, + "node_modules/entities": { + "version": "4.5.0", + "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz", + "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==", + "engines": { + "node": ">=0.12" + }, + "funding": { + "url": "https://github.com/fb55/entities?sponsor=1" + } + }, + "node_modules/error-ex": { + "version": "1.3.2", + "resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.2.tgz", + "integrity": "sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==", + "dependencies": { + "is-arrayish": "^0.2.1" + } + }, + "node_modules/es-abstract": { + "version": "1.22.1", + "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.22.1.tgz", + "integrity": "sha512-ioRRcXMO6OFyRpyzV3kE1IIBd4WG5/kltnzdxSCqoP8CMGs/Li+M1uF5o7lOkZVFjDs+NLesthnF66Pg/0q0Lw==", + "dev": true, + "dependencies": { + "array-buffer-byte-length": "^1.0.0", + "arraybuffer.prototype.slice": "^1.0.1", + "available-typed-arrays": "^1.0.5", + "call-bind": "^1.0.2", + "es-set-tostringtag": "^2.0.1", + "es-to-primitive": "^1.2.1", + "function.prototype.name": "^1.1.5", + "get-intrinsic": "^1.2.1", + "get-symbol-description": "^1.0.0", + "globalthis": "^1.0.3", + "gopd": "^1.0.1", + "has": "^1.0.3", + "has-property-descriptors": "^1.0.0", + "has-proto": "^1.0.1", + "has-symbols": "^1.0.3", + "internal-slot": "^1.0.5", + "is-array-buffer": "^3.0.2", + "is-callable": "^1.2.7", + "is-negative-zero": "^2.0.2", + "is-regex": "^1.1.4", + "is-shared-array-buffer": "^1.0.2", + "is-string": "^1.0.7", + "is-typed-array": "^1.1.10", + "is-weakref": "^1.0.2", + "object-inspect": "^1.12.3", + "object-keys": "^1.1.1", + "object.assign": "^4.1.4", + "regexp.prototype.flags": "^1.5.0", + "safe-array-concat": "^1.0.0", + "safe-regex-test": "^1.0.0", + "string.prototype.trim": "^1.2.7", + "string.prototype.trimend": "^1.0.6", + "string.prototype.trimstart": "^1.0.6", + "typed-array-buffer": "^1.0.0", + "typed-array-byte-length": "^1.0.0", + "typed-array-byte-offset": "^1.0.0", + "typed-array-length": "^1.0.4", + "unbox-primitive": "^1.0.2", + "which-typed-array": "^1.1.10" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/es-set-tostringtag": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/es-set-tostringtag/-/es-set-tostringtag-2.0.1.tgz", + "integrity": "sha512-g3OMbtlwY3QewlqAiMLI47KywjWZoEytKr8pf6iTC8uJq5bIAH52Z9pnQ8pVL6whrCto53JZDuUIsifGeLorTg==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.1.3", + "has": "^1.0.3", + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/es-shim-unscopables": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/es-shim-unscopables/-/es-shim-unscopables-1.0.0.tgz", + "integrity": "sha512-Jm6GPcCdC30eMLbZ2x8z2WuRwAws3zTBBKuusffYVUrNj/GVSUAZ+xKMaUpfNDR5IbyNA5LJbaecoUVbmUcB1w==", + "dev": true, + "dependencies": { + "has": "^1.0.3" + } + }, + "node_modules/es-to-primitive": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/es-to-primitive/-/es-to-primitive-1.2.1.tgz", + "integrity": "sha512-QCOllgZJtaUo9miYBcLChTUaHNjJF3PYs1VidD7AwiEj1kYxKeQTctLAezAOH5ZKRH0g2IgPn6KwB4IT8iRpvA==", + "dev": true, + "dependencies": { + "is-callable": "^1.1.4", + "is-date-object": "^1.0.1", + "is-symbol": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/escape-string-regexp": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-4.0.0.tgz", + "integrity": "sha512-TtpcNJ3XAzx3Gq8sWRzJaVajRs0uVxA2YAkdb1jm2YkPz4G6egUFAyA3n5vtEIZefPk5Wa4UXbKuS5fKkJWdgA==", + "dev": true, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/eslint": { + "version": "8.47.0", + "resolved": "https://registry.npmjs.org/eslint/-/eslint-8.47.0.tgz", + "integrity": "sha512-spUQWrdPt+pRVP1TTJLmfRNJJHHZryFmptzcafwSvHsceV81djHOdnEeDmkdotZyLNjDhrOasNK8nikkoG1O8Q==", + "dev": true, + "dependencies": { + "@eslint-community/eslint-utils": "^4.2.0", + "@eslint-community/regexpp": "^4.6.1", + "@eslint/eslintrc": "^2.1.2", + "@eslint/js": "^8.47.0", + "@humanwhocodes/config-array": "^0.11.10", + "@humanwhocodes/module-importer": "^1.0.1", + "@nodelib/fs.walk": "^1.2.8", + "ajv": "^6.12.4", + "chalk": "^4.0.0", + "cross-spawn": "^7.0.2", + "debug": "^4.3.2", + "doctrine": "^3.0.0", + "escape-string-regexp": "^4.0.0", + "eslint-scope": "^7.2.2", + "eslint-visitor-keys": "^3.4.3", + "espree": "^9.6.1", + "esquery": "^1.4.2", + "esutils": "^2.0.2", + "fast-deep-equal": "^3.1.3", + "file-entry-cache": "^6.0.1", + "find-up": "^5.0.0", + "glob-parent": "^6.0.2", + "globals": "^13.19.0", + "graphemer": "^1.4.0", + "ignore": "^5.2.0", + "imurmurhash": "^0.1.4", + "is-glob": "^4.0.0", + "is-path-inside": "^3.0.3", + "js-yaml": "^4.1.0", + "json-stable-stringify-without-jsonify": "^1.0.1", + "levn": "^0.4.1", + "lodash.merge": "^4.6.2", + "minimatch": "^3.1.2", + "natural-compare": "^1.4.0", + "optionator": "^0.9.3", + "strip-ansi": "^6.0.1", + "text-table": "^0.2.0" + }, + "bin": { + "eslint": "bin/eslint.js" + }, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "funding": { + "url": "https://opencollective.com/eslint" + } + }, + "node_modules/eslint-import-resolver-node": { + "version": "0.3.9", + "resolved": "https://registry.npmjs.org/eslint-import-resolver-node/-/eslint-import-resolver-node-0.3.9.tgz", + "integrity": "sha512-WFj2isz22JahUv+B788TlO3N6zL3nNJGU8CcZbPZvVEkBPaJdCV4vy5wyghty5ROFbCRnm132v8BScu5/1BQ8g==", + "dev": true, + "dependencies": { + "debug": "^3.2.7", + "is-core-module": "^2.13.0", + "resolve": "^1.22.4" + } + }, + "node_modules/eslint-import-resolver-node/node_modules/debug": { + "version": "3.2.7", + "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", + "integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==", + "dev": true, + "dependencies": { + "ms": "^2.1.1" + } + }, + "node_modules/eslint-module-utils": { + "version": "2.8.0", + "resolved": "https://registry.npmjs.org/eslint-module-utils/-/eslint-module-utils-2.8.0.tgz", + "integrity": "sha512-aWajIYfsqCKRDgUfjEXNN/JlrzauMuSEy5sbd7WXbtW3EH6A6MpwEh42c7qD+MqQo9QMJ6fWLAeIJynx0g6OAw==", + "dev": true, + "dependencies": { + "debug": "^3.2.7" + }, + "engines": { + "node": ">=4" + }, + "peerDependenciesMeta": { + "eslint": { + "optional": true + } + } + }, + "node_modules/eslint-module-utils/node_modules/debug": { + "version": "3.2.7", + "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", + "integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==", + "dev": true, + "dependencies": { + "ms": "^2.1.1" + } + }, + "node_modules/eslint-plugin-import": { + "version": "2.28.0", + "resolved": "https://registry.npmjs.org/eslint-plugin-import/-/eslint-plugin-import-2.28.0.tgz", + "integrity": "sha512-B8s/n+ZluN7sxj9eUf7/pRFERX0r5bnFA2dCaLHy2ZeaQEAz0k+ZZkFWRFHJAqxfxQDx6KLv9LeIki7cFdwW+Q==", + "dev": true, + "dependencies": { + "array-includes": "^3.1.6", + "array.prototype.findlastindex": "^1.2.2", + "array.prototype.flat": "^1.3.1", + "array.prototype.flatmap": "^1.3.1", + "debug": "^3.2.7", + "doctrine": "^2.1.0", + "eslint-import-resolver-node": "^0.3.7", + "eslint-module-utils": "^2.8.0", + "has": "^1.0.3", + "is-core-module": "^2.12.1", + "is-glob": "^4.0.3", + "minimatch": "^3.1.2", + "object.fromentries": "^2.0.6", + "object.groupby": "^1.0.0", + "object.values": "^1.1.6", + "resolve": "^1.22.3", + "semver": "^6.3.1", + "tsconfig-paths": "^3.14.2" + }, + "engines": { + "node": ">=4" + }, + "peerDependencies": { + "eslint": "^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8" + } + }, + "node_modules/eslint-plugin-import/node_modules/debug": { + "version": "3.2.7", + "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", + "integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==", + "dev": true, + "dependencies": { + "ms": "^2.1.1" + } + }, + "node_modules/eslint-plugin-import/node_modules/doctrine": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/doctrine/-/doctrine-2.1.0.tgz", + "integrity": "sha512-35mSku4ZXK0vfCuHEDAwt55dg2jNajHZ1odvF+8SSr82EsZY4QmXfuWso8oEd8zRhVObSN18aM0CjSdoBX7zIw==", + "dev": true, + "dependencies": { + "esutils": "^2.0.2" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/eslint-scope": { + "version": "7.2.2", + "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-7.2.2.tgz", + "integrity": "sha512-dOt21O7lTMhDM+X9mB4GX+DZrZtCUJPL/wlcTqxyrx5IvO0IYtILdtrQGQp+8n5S0gwSVmOf9NQrjMOgfQZlIg==", + "dev": true, + "dependencies": { + "esrecurse": "^4.3.0", + "estraverse": "^5.2.0" + }, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "funding": { + "url": "https://opencollective.com/eslint" + } + }, + "node_modules/eslint-visitor-keys": { + "version": "3.4.3", + "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-3.4.3.tgz", + "integrity": "sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==", + "dev": true, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "funding": { + "url": "https://opencollective.com/eslint" + } + }, + "node_modules/espree": { + "version": "9.6.1", + "resolved": "https://registry.npmjs.org/espree/-/espree-9.6.1.tgz", + "integrity": "sha512-oruZaFkjorTpF32kDSI5/75ViwGeZginGGy2NoOSg3Q9bnwlnmDm4HLnkl0RE3n+njDXR037aY1+x58Z/zFdwQ==", + "dev": true, + "dependencies": { + "acorn": "^8.9.0", + "acorn-jsx": "^5.3.2", + "eslint-visitor-keys": "^3.4.1" + }, + "engines": { + "node": "^12.22.0 || ^14.17.0 || >=16.0.0" + }, + "funding": { + "url": "https://opencollective.com/eslint" + } + }, + "node_modules/esquery": { + "version": "1.5.0", + "resolved": "https://registry.npmjs.org/esquery/-/esquery-1.5.0.tgz", + "integrity": "sha512-YQLXUplAwJgCydQ78IMJywZCceoqk1oH01OERdSAJc/7U2AylwjhSCLDEtqwg811idIS/9fIU5GjG73IgjKMVg==", + "dev": true, + "dependencies": { + "estraverse": "^5.1.0" + }, + "engines": { + "node": ">=0.10" + } + }, + "node_modules/esrecurse": { + "version": "4.3.0", + "resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz", + "integrity": "sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==", + "dev": true, + "dependencies": { + "estraverse": "^5.2.0" + }, + "engines": { + "node": ">=4.0" + } + }, + "node_modules/estraverse": { + "version": "5.3.0", + "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz", + "integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==", + "dev": true, + "engines": { + "node": ">=4.0" + } + }, + "node_modules/esutils": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/esutils/-/esutils-2.0.3.tgz", + "integrity": "sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/extend": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz", + "integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==" + }, + "node_modules/external-editor": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/external-editor/-/external-editor-3.1.0.tgz", + "integrity": "sha512-hMQ4CX1p1izmuLYyZqLMO/qGNw10wSv9QDCPfzXfyFrOaCSSoRfqE1Kf1s5an66J5JZC62NewG+mK49jOCtQew==", + "dependencies": { + "chardet": "^0.7.0", + "iconv-lite": "^0.4.24", + "tmp": "^0.0.33" + }, + "engines": { + "node": ">=4" + } + }, + "node_modules/fast-deep-equal": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz", + "integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==", + "dev": true + }, + "node_modules/fast-json-stable-stringify": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz", + "integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==", + "dev": true + }, + "node_modules/fast-levenshtein": { + "version": "2.0.6", + "resolved": "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz", + "integrity": "sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==", + "dev": true + }, + "node_modules/fastq": { + "version": "1.15.0", + "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.15.0.tgz", + "integrity": "sha512-wBrocU2LCXXa+lWBt8RoIRD89Fi8OdABODa/kEnyeyjS5aZO5/GNvI5sEINADqP/h8M29UHTHUb53sUu5Ihqdw==", + "dev": true, + "dependencies": { + "reusify": "^1.0.4" + } + }, + "node_modules/fault": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/fault/-/fault-2.0.1.tgz", + "integrity": "sha512-WtySTkS4OKev5JtpHXnib4Gxiurzh5NCGvWrFaZ34m6JehfTUhKZvn9njTfw48t6JumVQOmrKqpmGcdwxnhqBQ==", + "dependencies": { + "format": "^0.2.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/figures": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/figures/-/figures-3.2.0.tgz", + "integrity": "sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg==", + "dependencies": { + "escape-string-regexp": "^1.0.5" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/figures/node_modules/escape-string-regexp": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", + "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", + "engines": { + "node": ">=0.8.0" + } + }, + "node_modules/file-entry-cache": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-6.0.1.tgz", + "integrity": "sha512-7Gps/XWymbLk2QLYK4NzpMOrYjMhdIxXuIvy2QBsLE6ljuodKvdkWs/cpyJJ3CVIVpH0Oi1Hvg1ovbMzLdFBBg==", + "dev": true, + "dependencies": { + "flat-cache": "^3.0.4" + }, + "engines": { + "node": "^10.12.0 || >=12.0.0" + } + }, + "node_modules/fill-range": { + "version": "7.0.1", + "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz", + "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==", + "dependencies": { + "to-regex-range": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/find-up": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/find-up/-/find-up-5.0.0.tgz", + "integrity": "sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==", + "dev": true, + "dependencies": { + "locate-path": "^6.0.0", + "path-exists": "^4.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/flat-cache": { + "version": "3.0.4", + "resolved": "https://registry.npmjs.org/flat-cache/-/flat-cache-3.0.4.tgz", + "integrity": "sha512-dm9s5Pw7Jc0GvMYbshN6zchCA9RgQlzzEZX3vylR9IqFfS8XciblUXOKfW6SiuJ0e13eDYZoZV5wdrev7P3Nwg==", + "dev": true, + "dependencies": { + "flatted": "^3.1.0", + "rimraf": "^3.0.2" + }, + "engines": { + "node": "^10.12.0 || >=12.0.0" + } + }, + "node_modules/flatted": { + "version": "3.2.7", + "resolved": "https://registry.npmjs.org/flatted/-/flatted-3.2.7.tgz", + "integrity": "sha512-5nqDSxl8nn5BSNxyR3n4I6eDmbolI6WT+QqR547RwxQapgjQBmtktdP+HTBb/a/zLsbzERTONyUB5pefh5TtjQ==", + "dev": true + }, + "node_modules/follow-redirects": { + "version": "1.15.2", + "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.2.tgz", + "integrity": "sha512-VQLG33o04KaQ8uYi2tVNbdrWp1QWxNNea+nmIB4EVM28v0hmP17z7aG1+wAkNzVq4KeXTq3221ye5qTJP91JwA==", + "funding": [ + { + "type": "individual", + "url": "https://github.com/sponsors/RubenVerborgh" + } + ], + "engines": { + "node": ">=4.0" + }, + "peerDependenciesMeta": { + "debug": { + "optional": true + } + } + }, + "node_modules/for-each": { + "version": "0.3.3", + "resolved": "https://registry.npmjs.org/for-each/-/for-each-0.3.3.tgz", + "integrity": "sha512-jqYfLp7mo9vIyQf8ykW2v7A+2N4QjeCeI5+Dz9XraiO1ign81wjiH7Fb9vSOWvQfNtmSa4H2RoQTrrXivdUZmw==", + "dev": true, + "dependencies": { + "is-callable": "^1.1.3" + } + }, + "node_modules/foreground-child": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.1.1.tgz", + "integrity": "sha512-TMKDUnIte6bfb5nWv7V/caI169OHgvwjb7V4WkeUvbQQdjr5rWKqHFiKWb/fcOwB+CzBT+qbWjvj+DVwRskpIg==", + "dependencies": { + "cross-spawn": "^7.0.0", + "signal-exit": "^4.0.1" + }, + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/foreground-child/node_modules/signal-exit": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", + "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/format": { + "version": "0.2.2", + "resolved": "https://registry.npmjs.org/format/-/format-0.2.2.tgz", + "integrity": "sha512-wzsgA6WOq+09wrU1tsJ09udeR/YZRaeArL9e1wPbFg3GG2yDnC2ldKpxs4xunpFF9DgqCqOIra3bc1HWrJ37Ww==", + "engines": { + "node": ">=0.4.x" + } + }, + "node_modules/fs-extra": { + "version": "10.1.0", + "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-10.1.0.tgz", + "integrity": "sha512-oRXApq54ETRj4eMiFzGnHWGy+zo5raudjuxN0b8H7s/RU2oW0Wvsx9O0ACRN/kRq9E8Vu/ReskGB5o3ji+FzHQ==", + "dependencies": { + "graceful-fs": "^4.2.0", + "jsonfile": "^6.0.1", + "universalify": "^2.0.0" + }, + "engines": { + "node": ">=12" + } + }, + "node_modules/fs.realpath": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", + "integrity": "sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==" + }, + "node_modules/fsevents": { + "version": "2.3.2", + "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.2.tgz", + "integrity": "sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==", + "hasInstallScript": true, + "optional": true, + "os": [ + "darwin" + ], + "engines": { + "node": "^8.16.0 || ^10.6.0 || >=11.0.0" + } + }, + "node_modules/function-bind": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.1.tgz", + "integrity": "sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==", + "dev": true + }, + "node_modules/function.prototype.name": { + "version": "1.1.5", + "resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.5.tgz", + "integrity": "sha512-uN7m/BzVKQnCUF/iW8jYea67v++2u7m5UgENbHRtdDVclOUP+FMPlCNdmk0h/ysGyo2tavMJEDqJAkJdRa1vMA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.3", + "es-abstract": "^1.19.0", + "functions-have-names": "^1.2.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/functions-have-names": { + "version": "1.2.3", + "resolved": "https://registry.npmjs.org/functions-have-names/-/functions-have-names-1.2.3.tgz", + "integrity": "sha512-xckBUXyTIqT97tq2x2AMb+g163b5JFysYk0x4qxNFwbfQkmNZoiRHb6sPzI9/QV33WeuvVYBUIiD4NzNIyqaRQ==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/get-intrinsic": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.2.1.tgz", + "integrity": "sha512-2DcsyfABl+gVHEfCOaTrWgyt+tb6MSEGmKq+kI5HwLbIYgjgmMcV8KQ41uaKz1xxUcn9tJtgFbQUEVcEbd0FYw==", + "dev": true, + "dependencies": { + "function-bind": "^1.1.1", + "has": "^1.0.3", + "has-proto": "^1.0.1", + "has-symbols": "^1.0.3" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/get-symbol-description": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/get-symbol-description/-/get-symbol-description-1.0.0.tgz", + "integrity": "sha512-2EmdH1YvIQiZpltCNgkuiUnyukzxM/R6NDJX31Ke3BG1Nq5b0S2PhX59UKi9vZpPDQVdqn+1IcaAwnzTT5vCjw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "get-intrinsic": "^1.1.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/github-slugger": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/github-slugger/-/github-slugger-2.0.0.tgz", + "integrity": "sha512-IaOQ9puYtjrkq7Y0Ygl9KDZnrf/aiUJYUpVf89y8kyaxbRG7Y1SrX/jaumrv81vc61+kiMempujsM3Yw7w5qcw==" + }, + "node_modules/glob": { + "version": "7.2.3", + "resolved": "https://registry.npmjs.org/glob/-/glob-7.2.3.tgz", + "integrity": "sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==", + "dev": true, + "dependencies": { + "fs.realpath": "^1.0.0", + "inflight": "^1.0.4", + "inherits": "2", + "minimatch": "^3.1.1", + "once": "^1.3.0", + "path-is-absolute": "^1.0.0" + }, + "engines": { + "node": "*" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/glob-parent": { + "version": "6.0.2", + "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz", + "integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==", + "dev": true, + "dependencies": { + "is-glob": "^4.0.3" + }, + "engines": { + "node": ">=10.13.0" + } + }, + "node_modules/globals": { + "version": "13.21.0", + "resolved": "https://registry.npmjs.org/globals/-/globals-13.21.0.tgz", + "integrity": "sha512-ybyme3s4yy/t/3s35bewwXKOf7cvzfreG2lH0lZl0JB7I4GxRP2ghxOK/Nb9EkRXdbBXZLfq/p/0W2JUONB/Gg==", + "dev": true, + "dependencies": { + "type-fest": "^0.20.2" + }, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/globalthis": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/globalthis/-/globalthis-1.0.3.tgz", + "integrity": "sha512-sFdI5LyBiNTHjRd7cGPWapiHWMOXKyuBNX/cWJ3NfzrZQVa8GI/8cofCl74AOVqq9W5kNmguTIzJ/1s2gyI9wA==", + "dev": true, + "dependencies": { + "define-properties": "^1.1.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/gopd": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/gopd/-/gopd-1.0.1.tgz", + "integrity": "sha512-d65bNlIadxvpb/A2abVdlqKqV563juRnZ1Wtk6s1sIR8uNsXR70xqIzVqxVf1eTqDunwT2MkczEeaezCKTZhwA==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.1.3" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/graceful-fs": { + "version": "4.2.11", + "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz", + "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==" + }, + "node_modules/graphemer": { + "version": "1.4.0", + "resolved": "https://registry.npmjs.org/graphemer/-/graphemer-1.4.0.tgz", + "integrity": "sha512-EtKwoO6kxCL9WO5xipiHTZlSzBm7WLT627TqC/uVRd0HKmq8NXyebnNYxDoBi7wt8eTWrUrKXCOVaFq9x1kgag==", + "dev": true + }, + "node_modules/has": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/has/-/has-1.0.3.tgz", + "integrity": "sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==", + "dev": true, + "dependencies": { + "function-bind": "^1.1.1" + }, + "engines": { + "node": ">= 0.4.0" + } + }, + "node_modules/has-bigints": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/has-bigints/-/has-bigints-1.0.2.tgz", + "integrity": "sha512-tSvCKtBr9lkF0Ex0aQiP9N+OpV4zi2r/Nee5VkRDbaqv35RLYMzbwQfFSZZH0kR+Rd6302UJZ2p/bJCEoR3VoQ==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-flag": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", + "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==", + "engines": { + "node": ">=8" + } + }, + "node_modules/has-property-descriptors": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/has-property-descriptors/-/has-property-descriptors-1.0.0.tgz", + "integrity": "sha512-62DVLZGoiEBDHQyqG4w9xCuZ7eJEwNmJRWw2VY84Oedb7WFcA27fiEVe8oUQx9hAUJ4ekurquucTGwsyO1XGdQ==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.1.1" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-proto": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/has-proto/-/has-proto-1.0.1.tgz", + "integrity": "sha512-7qE+iP+O+bgF9clE5+UoBFzE65mlBiVj3tKCrlNQ0Ogwm0BjpT/gK4SlLYDMybDh5I3TCTKnPPa0oMG7JDYrhg==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-symbols": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.3.tgz", + "integrity": "sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/has-tostringtag": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/has-tostringtag/-/has-tostringtag-1.0.0.tgz", + "integrity": "sha512-kFjcSNhnlGV1kyoGk7OXKSawH5JOb/LzUc5w9B02hOTO0dfFRjbHQKvg1d6cf3HbeUmtU9VbbV3qzZ2Teh97WQ==", + "dev": true, + "dependencies": { + "has-symbols": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/hast-util-from-parse5": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-7.1.2.tgz", + "integrity": "sha512-Nz7FfPBuljzsN3tCQ4kCBKqdNhQE2l0Tn+X1ubgKBPRoiDIu1mL08Cfw4k7q71+Duyaw7DXDN+VTAp4Vh3oCOw==", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/unist": "^2.0.0", + "hastscript": "^7.0.0", + "property-information": "^6.0.0", + "vfile": "^5.0.0", + "vfile-location": "^4.0.0", + "web-namespaces": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-parse-selector": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-3.1.1.tgz", + "integrity": "sha512-jdlwBjEexy1oGz0aJ2f4GKMaVKkA9jwjr4MjAAI22E5fM/TXVZHuS5OpONtdeIkRKqAaryQ2E9xNQxijoThSZA==", + "dependencies": { + "@types/hast": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-raw": { + "version": "7.2.3", + "resolved": "https://registry.npmjs.org/hast-util-raw/-/hast-util-raw-7.2.3.tgz", + "integrity": "sha512-RujVQfVsOrxzPOPSzZFiwofMArbQke6DJjnFfceiEbFh7S05CbPt0cYN+A5YeD3pso0JQk6O1aHBnx9+Pm2uqg==", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/parse5": "^6.0.0", + "hast-util-from-parse5": "^7.0.0", + "hast-util-to-parse5": "^7.0.0", + "html-void-elements": "^2.0.0", + "parse5": "^6.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0", + "vfile": "^5.0.0", + "web-namespaces": "^2.0.0", + "zwitch": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-to-html": { + "version": "8.0.4", + "resolved": "https://registry.npmjs.org/hast-util-to-html/-/hast-util-to-html-8.0.4.tgz", + "integrity": "sha512-4tpQTUOr9BMjtYyNlt0P50mH7xj0Ks2xpo8M943Vykljf99HW6EzulIoJP1N3eKOSScEHzyzi9dm7/cn0RfGwA==", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/unist": "^2.0.0", + "ccount": "^2.0.0", + "comma-separated-tokens": "^2.0.0", + "hast-util-raw": "^7.0.0", + "hast-util-whitespace": "^2.0.0", + "html-void-elements": "^2.0.0", + "property-information": "^6.0.0", + "space-separated-tokens": "^2.0.0", + "stringify-entities": "^4.0.0", + "zwitch": "^2.0.4" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-to-parse5": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/hast-util-to-parse5/-/hast-util-to-parse5-7.1.0.tgz", + "integrity": "sha512-YNRgAJkH2Jky5ySkIqFXTQiaqcAtJyVE+D5lkN6CdtOqrnkLfGYYrEcKuHOJZlp+MwjSwuD3fZuawI+sic/RBw==", + "dependencies": { + "@types/hast": "^2.0.0", + "comma-separated-tokens": "^2.0.0", + "property-information": "^6.0.0", + "space-separated-tokens": "^2.0.0", + "web-namespaces": "^2.0.0", + "zwitch": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-whitespace": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/hast-util-whitespace/-/hast-util-whitespace-2.0.1.tgz", + "integrity": "sha512-nAxA0v8+vXSBDt3AnRUNjyRIQ0rD+ntpbAp4LnPkumc5M9yUbSMa4XDU9Q6etY4f1Wp4bNgvc1yjiZtsTTrSng==", + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hastscript": { + "version": "7.2.0", + "resolved": "https://registry.npmjs.org/hastscript/-/hastscript-7.2.0.tgz", + "integrity": "sha512-TtYPq24IldU8iKoJQqvZOuhi5CyCQRAbvDOX0x1eW6rsHSxa/1i2CCiptNTotGHJ3VoHRGmqiv6/D3q113ikkw==", + "dependencies": { + "@types/hast": "^2.0.0", + "comma-separated-tokens": "^2.0.0", + "hast-util-parse-selector": "^3.0.0", + "property-information": "^6.0.0", + "space-separated-tokens": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hosted-git-info": { + "version": "6.1.1", + "resolved": "https://registry.npmjs.org/hosted-git-info/-/hosted-git-info-6.1.1.tgz", + "integrity": "sha512-r0EI+HBMcXadMrugk0GCQ+6BQV39PiWAZVfq7oIckeGiN7sjRGyQxPdft3nQekFTCQbYxLBH+/axZMeH8UX6+w==", + "dependencies": { + "lru-cache": "^7.5.1" + }, + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/html-void-elements": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/html-void-elements/-/html-void-elements-2.0.1.tgz", + "integrity": "sha512-0quDb7s97CfemeJAnW9wC0hw78MtW7NU3hqtCD75g2vFlDLt36llsYD7uB7SUzojLMP24N5IatXf7ylGXiGG9A==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/htmlparser2": { + "version": "8.0.2", + "resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-8.0.2.tgz", + "integrity": "sha512-GYdjWKDkbRLkZ5geuHs5NY1puJ+PXwP7+fHPRz06Eirsb9ugf6d8kkXav6ADhcODhFFPMIXyxkxSuMf3D6NCFA==", + "funding": [ + "https://github.com/fb55/htmlparser2?sponsor=1", + { + "type": "github", + "url": "https://github.com/sponsors/fb55" + } + ], + "dependencies": { + "domelementtype": "^2.3.0", + "domhandler": "^5.0.3", + "domutils": "^3.0.1", + "entities": "^4.4.0" + } + }, + "node_modules/iconv-lite": { + "version": "0.4.24", + "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz", + "integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==", + "dependencies": { + "safer-buffer": ">= 2.1.2 < 3" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/ieee754": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz", + "integrity": "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/ignore": { + "version": "5.2.4", + "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.2.4.tgz", + "integrity": "sha512-MAb38BcSbH0eHNBxn7ql2NH/kX33OkB3lZ1BNdh7ENeRChHTYsTvWrMubiIAMNS2llXEEgZ1MUOBtXChP3kaFQ==", + "engines": { + "node": ">= 4" + } + }, + "node_modules/import-fresh": { + "version": "3.3.0", + "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz", + "integrity": "sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==", + "dev": true, + "dependencies": { + "parent-module": "^1.0.0", + "resolve-from": "^4.0.0" + }, + "engines": { + "node": ">=6" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/import-meta-resolve": { + "version": "2.2.2", + "resolved": "https://registry.npmjs.org/import-meta-resolve/-/import-meta-resolve-2.2.2.tgz", + "integrity": "sha512-f8KcQ1D80V7RnqVm+/lirO9zkOxjGxhaTC1IPrBGd3MEfNgmNG67tSUO9gTi2F3Blr2Az6g1vocaxzkVnWl9MA==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/imurmurhash": { + "version": "0.1.4", + "resolved": "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz", + "integrity": "sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==", + "dev": true, + "engines": { + "node": ">=0.8.19" + } + }, + "node_modules/inflight": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", + "integrity": "sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==", + "dependencies": { + "once": "^1.3.0", + "wrappy": "1" + } + }, + "node_modules/inherits": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", + "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==" + }, + "node_modules/ini": { + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/ini/-/ini-4.1.1.tgz", + "integrity": "sha512-QQnnxNyfvmHFIsj7gkPcYymR8Jdw/o7mp5ZFihxn6h8Ci6fh3Dx4E1gPjpQEpIuPo9XVNY/ZUwh4BPMjGyL01g==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/inquirer": { + "version": "8.2.6", + "resolved": "https://registry.npmjs.org/inquirer/-/inquirer-8.2.6.tgz", + "integrity": "sha512-M1WuAmb7pn9zdFRtQYk26ZBoY043Sse0wVDdk4Bppr+JOXyQYybdtvK+l9wUibhtjdjvtoiNy8tk+EgsYIUqKg==", + "dependencies": { + "ansi-escapes": "^4.2.1", + "chalk": "^4.1.1", + "cli-cursor": "^3.1.0", + "cli-width": "^3.0.0", + "external-editor": "^3.0.3", + "figures": "^3.0.0", + "lodash": "^4.17.21", + "mute-stream": "0.0.8", + "ora": "^5.4.1", + "run-async": "^2.4.0", + "rxjs": "^7.5.5", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0", + "through": "^2.3.6", + "wrap-ansi": "^6.0.1" + }, + "engines": { + "node": ">=12.0.0" + } + }, + "node_modules/internal-slot": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/internal-slot/-/internal-slot-1.0.5.tgz", + "integrity": "sha512-Y+R5hJrzs52QCG2laLn4udYVnxsfny9CpOhNhUvk/SSSVyF6T27FzRbF0sroPidSu3X8oEAkOn2K804mjpt6UQ==", + "dev": true, + "dependencies": { + "get-intrinsic": "^1.2.0", + "has": "^1.0.3", + "side-channel": "^1.0.4" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/is-array-buffer": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/is-array-buffer/-/is-array-buffer-3.0.2.tgz", + "integrity": "sha512-y+FyyR/w8vfIRq4eQcM1EYgSTnmHXPqaF+IgzgraytCFq5Xh8lllDVmAZolPJiZttZLeFSINPYMaEJ7/vWUa1w==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "get-intrinsic": "^1.2.0", + "is-typed-array": "^1.1.10" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-arrayish": { + "version": "0.2.1", + "resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz", + "integrity": "sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg==" + }, + "node_modules/is-bigint": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/is-bigint/-/is-bigint-1.0.4.tgz", + "integrity": "sha512-zB9CruMamjym81i2JZ3UMn54PKGsQzsJeo6xvN3HJJ4CAsQNB6iRutp2To77OfCNuoxspsIhzaPoO1zyCEhFOg==", + "dev": true, + "dependencies": { + "has-bigints": "^1.0.1" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-binary-path": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz", + "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==", + "dependencies": { + "binary-extensions": "^2.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/is-boolean-object": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/is-boolean-object/-/is-boolean-object-1.1.2.tgz", + "integrity": "sha512-gDYaKHJmnj4aWxyj6YHyXVpdQawtVLHU5cb+eztPGczf6cjuTdwve5ZIEfgXqH4e57An1D1AKf8CZ3kYrQRqYA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-buffer": { + "version": "1.1.6", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-1.1.6.tgz", + "integrity": "sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==" + }, + "node_modules/is-callable": { + "version": "1.2.7", + "resolved": "https://registry.npmjs.org/is-callable/-/is-callable-1.2.7.tgz", + "integrity": "sha512-1BC0BVFhS/p0qtw6enp8e+8OD0UrK0oFLztSjNzhcKA3WDuJxxAPXzPuPtKkjEY9UUoEWlX/8fgKeu2S8i9JTA==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-core-module": { + "version": "2.13.0", + "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.13.0.tgz", + "integrity": "sha512-Z7dk6Qo8pOCp3l4tsX2C5ZVas4V+UxwQodwZhLopL91TX8UyyHEXafPcyoeeWuLrwzHcr3igO78wNLwHJHsMCQ==", + "dev": true, + "dependencies": { + "has": "^1.0.3" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-date-object": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/is-date-object/-/is-date-object-1.0.5.tgz", + "integrity": "sha512-9YQaSxsAiSwcvS33MBk3wTCVnWK+HhF8VZR2jRxehM16QcVOdHqPn4VPHmRK4lSr38n9JriurInLcP90xsYNfQ==", + "dev": true, + "dependencies": { + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-empty": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/is-empty/-/is-empty-1.2.0.tgz", + "integrity": "sha512-F2FnH/otLNJv0J6wc73A5Xo7oHLNnqplYqZhUu01tD54DIPvxIRSTSLkrUB/M0nHO4vo1O9PDfN4KoTxCzLh/w==" + }, + "node_modules/is-extglob": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", + "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==", + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/is-fullwidth-code-point": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", + "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==", + "engines": { + "node": ">=8" + } + }, + "node_modules/is-glob": { + "version": "4.0.3", + "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz", + "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==", + "dependencies": { + "is-extglob": "^2.1.1" + }, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/is-interactive": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/is-interactive/-/is-interactive-1.0.0.tgz", + "integrity": "sha512-2HvIEKRoqS62guEC+qBjpvRubdX910WCMuJTZ+I9yvqKU2/12eSL549HMwtabb4oupdj2sMP50k+XJfB/8JE6w==", + "engines": { + "node": ">=8" + } + }, + "node_modules/is-negative-zero": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/is-negative-zero/-/is-negative-zero-2.0.2.tgz", + "integrity": "sha512-dqJvarLawXsFbNDeJW7zAz8ItJ9cd28YufuuFzh0G8pNHjJMnY08Dv7sYX2uF5UpQOwieAeOExEYAWWfu7ZZUA==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-number": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", + "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", + "engines": { + "node": ">=0.12.0" + } + }, + "node_modules/is-number-object": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/is-number-object/-/is-number-object-1.0.7.tgz", + "integrity": "sha512-k1U0IRzLMo7ZlYIfzRu23Oh6MiIFasgpb9X76eqfFZAqwH44UI4KTBvBYIZ1dSL9ZzChTB9ShHfLkR4pdW5krQ==", + "dev": true, + "dependencies": { + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-path-inside": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-3.0.3.tgz", + "integrity": "sha512-Fd4gABb+ycGAmKou8eMftCupSir5lRxqf4aD/vd0cD2qc4HL07OjCeuHMr8Ro4CoMaeCKDB0/ECBOVWjTwUvPQ==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/is-plain-obj": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-4.1.0.tgz", + "integrity": "sha512-+Pgi+vMuUNkJyExiMBt5IlFoMyKnr5zhJ4Uspz58WOhBF5QoIZkFyNHIbBAtHwzVAgk5RtndVNsDRN61/mmDqg==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-regex": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/is-regex/-/is-regex-1.1.4.tgz", + "integrity": "sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-shared-array-buffer": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/is-shared-array-buffer/-/is-shared-array-buffer-1.0.2.tgz", + "integrity": "sha512-sqN2UDu1/0y6uvXyStCOzyhAjCSlHceFoMKJW8W9EU9cvic/QdsZ0kEU93HEy3IUEFZIiH/3w+AH/UQbPHNdhA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-string": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/is-string/-/is-string-1.0.7.tgz", + "integrity": "sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==", + "dev": true, + "dependencies": { + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-symbol": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/is-symbol/-/is-symbol-1.0.4.tgz", + "integrity": "sha512-C/CPBqKWnvdcxqIARxyOh4v1UUEOCHpgDa0WYgpKDFMszcrPcffg5uhwSgPCLD2WWxmq6isisz87tzT01tuGhg==", + "dev": true, + "dependencies": { + "has-symbols": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-typed-array": { + "version": "1.1.12", + "resolved": "https://registry.npmjs.org/is-typed-array/-/is-typed-array-1.1.12.tgz", + "integrity": "sha512-Z14TF2JNG8Lss5/HMqt0//T9JeHXttXy5pH/DBU4vi98ozO2btxzq9MwYDZYnKwU8nRsz/+GVFVRDq3DkVuSPg==", + "dev": true, + "dependencies": { + "which-typed-array": "^1.1.11" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-unicode-supported": { + "version": "0.1.0", + "resolved": "https://registry.npmjs.org/is-unicode-supported/-/is-unicode-supported-0.1.0.tgz", + "integrity": "sha512-knxG2q4UC3u8stRGyAVJCOdxFmv5DZiRcdlIaAQXAbSfJya+OhopNotLQrstBhququ4ZpuKbDc/8S6mgXgPFPw==", + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/is-weakref": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/is-weakref/-/is-weakref-1.0.2.tgz", + "integrity": "sha512-qctsuLZmIQ0+vSSMfoVvyFe2+GSEvnmZ2ezTup1SBse9+twCCeial6EEi3Nc2KFcf6+qz2FBPnjXsk8xhKSaPQ==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/isarray": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/isarray/-/isarray-2.0.5.tgz", + "integrity": "sha512-xHjhDr3cNBK0BzdUJSPXZntQUx/mwMS5Rw4A7lPJ90XGAO6ISP/ePDNuo0vhqOZU+UD5JoodwCAAoZQd3FeAKw==", + "dev": true + }, + "node_modules/isexe": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", + "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==" + }, + "node_modules/jackspeak": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-2.3.0.tgz", + "integrity": "sha512-uKmsITSsF4rUWQHzqaRUuyAir3fZfW3f202Ee34lz/gZCi970CPZwyQXLGNgWJvvZbvFyzeyGq0+4fcG/mBKZg==", + "dependencies": { + "@isaacs/cliui": "^8.0.2" + }, + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + }, + "optionalDependencies": { + "@pkgjs/parseargs": "^0.11.0" + } + }, + "node_modules/js-tokens": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-4.0.0.tgz", + "integrity": "sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==" + }, + "node_modules/js-yaml": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz", + "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==", + "dev": true, + "dependencies": { + "argparse": "^2.0.1" + }, + "bin": { + "js-yaml": "bin/js-yaml.js" + } + }, + "node_modules/json-parse-even-better-errors": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-2.3.1.tgz", + "integrity": "sha512-xyFwyhro/JEof6Ghe2iz2NcXoj2sloNsWr/XsERDK/oiPCfaNhl5ONfp+jQdAZRQQ0IJWNzH9zIZF7li91kh2w==" + }, + "node_modules/json-schema-traverse": { + "version": "0.4.1", + "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz", + "integrity": "sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==", + "dev": true + }, + "node_modules/json-stable-stringify-without-jsonify": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz", + "integrity": "sha512-Bdboy+l7tA3OGW6FjyFHWkP5LuByj1Tk33Ljyq0axyzdk9//JSi2u3fP1QSmd1KNwq6VOKYGlAu87CisVir6Pw==", + "dev": true + }, + "node_modules/json5": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/json5/-/json5-1.0.2.tgz", + "integrity": "sha512-g1MWMLBiz8FKi1e4w0UyVL3w+iJceWAFBAaBnnGKOpNa5f8TLktkbre1+s6oICydWAm+HRUGTmI+//xv2hvXYA==", + "dev": true, + "dependencies": { + "minimist": "^1.2.0" + }, + "bin": { + "json5": "lib/cli.js" + } + }, + "node_modules/jsonfile": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz", + "integrity": "sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==", + "dependencies": { + "universalify": "^2.0.0" + }, + "optionalDependencies": { + "graceful-fs": "^4.1.6" + } + }, + "node_modules/kleur": { + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/kleur/-/kleur-4.1.5.tgz", + "integrity": "sha512-o+NO+8WrRiQEE4/7nwRJhN1HWpVmJm511pBHUxPLtp0BUISzlBplORYSmTclCnJvQq2tKu/sgl3xVpkc7ZWuQQ==", + "engines": { + "node": ">=6" + } + }, + "node_modules/levenshtein-edit-distance": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/levenshtein-edit-distance/-/levenshtein-edit-distance-1.0.0.tgz", + "integrity": "sha512-gpgBvPn7IFIAL32f0o6Nsh2g+5uOvkt4eK9epTfgE4YVxBxwVhJ/p1888lMm/u8mXdu1ETLSi6zeEmkBI+0F3w==", + "bin": { + "levenshtein-edit-distance": "cli.js" + } + }, + "node_modules/levn": { + "version": "0.4.1", + "resolved": "https://registry.npmjs.org/levn/-/levn-0.4.1.tgz", + "integrity": "sha512-+bT2uH4E5LGE7h/n3evcS/sQlJXCpIp6ym8OWJ5eV6+67Dsql/LaaT7qJBAt2rzfoa/5QBGBhxDix1dMt2kQKQ==", + "dev": true, + "dependencies": { + "prelude-ls": "^1.2.1", + "type-check": "~0.4.0" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/lines-and-columns": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/lines-and-columns/-/lines-and-columns-2.0.3.tgz", + "integrity": "sha512-cNOjgCnLB+FnvWWtyRTzmB3POJ+cXxTA81LoW7u8JdmhfXzriropYwpjShnz1QLLWsQwY7nIxoDmcPTwphDK9w==", + "engines": { + "node": "^12.20.0 || ^14.13.1 || >=16.0.0" + } + }, + "node_modules/load-plugin": { + "version": "5.1.0", + "resolved": "https://registry.npmjs.org/load-plugin/-/load-plugin-5.1.0.tgz", + "integrity": "sha512-Lg1CZa1CFj2CbNaxijTL6PCbzd4qGTlZov+iH2p5Xwy/ApcZJh+i6jMN2cYePouTfjJfrNu3nXFdEw8LvbjPFQ==", + "dependencies": { + "@npmcli/config": "^6.0.0", + "import-meta-resolve": "^2.0.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/locate-path": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-6.0.0.tgz", + "integrity": "sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==", + "dev": true, + "dependencies": { + "p-locate": "^5.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/lodash": { + "version": "4.17.21", + "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz", + "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==" + }, + "node_modules/lodash.chunk": { + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/lodash.chunk/-/lodash.chunk-4.2.0.tgz", + "integrity": "sha512-ZzydJKfUHJwHa+hF5X66zLFCBrWn5GeF28OHEr4WVWtNDXlQ/IjWKPBiikqKo2ne0+v6JgCgJ0GzJp8k8bHC7w==" + }, + "node_modules/lodash.get": { + "version": "4.4.2", + "resolved": "https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz", + "integrity": "sha512-z+Uw/vLuy6gQe8cfaFWD7p0wVv8fJl3mbzXh33RS+0oW2wvUqiRXiQ69gLWSLpgB5/6sU+r6BlQR0MBILadqTQ==" + }, + "node_modules/lodash.merge": { + "version": "4.6.2", + "resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz", + "integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==", + "dev": true + }, + "node_modules/log-symbols": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/log-symbols/-/log-symbols-4.1.0.tgz", + "integrity": "sha512-8XPvpAA8uyhfteu8pIvQxpJZ7SYYdpUivZpGy6sFsBuKRY/7rQGavedeB8aK+Zkyq6upMFVL/9AW6vOYzfRyLg==", + "dependencies": { + "chalk": "^4.1.0", + "is-unicode-supported": "^0.1.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/longest-streak": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/longest-streak/-/longest-streak-3.1.0.tgz", + "integrity": "sha512-9Ri+o0JYgehTaVBBDoMqIl8GXtbWg711O3srftcHhZ0dqnETqLaoIK0x17fUw9rFSlK/0NlsKe0Ahhyl5pXE2g==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/lru-cache": { + "version": "7.18.3", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-7.18.3.tgz", + "integrity": "sha512-jumlc0BIUrS3qJGgIkWZsyfAM7NCWiBcCDhnd+3NNM5KbBmLTgHVfWBcg6W+rLUsIpzpERPsvwUP7CckAQSOoA==", + "engines": { + "node": ">=12" + } + }, + "node_modules/markdown-table": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.3.tgz", + "integrity": "sha512-Z1NL3Tb1M9wH4XESsCDEksWoKTdlUafKc4pt0GRwjUyXaCFZ+dc3g2erqB6zm3szA2IUSi7VnPI+o/9jnxh9hw==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/md5": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/md5/-/md5-2.3.0.tgz", + "integrity": "sha512-T1GITYmFaKuO91vxyoQMFETst+O71VUPEU3ze5GNzDm0OWdP8v1ziTaAEPUr/3kLsY3Sftgz242A1SetQiDL7g==", + "dependencies": { + "charenc": "0.0.2", + "crypt": "0.0.2", + "is-buffer": "~1.1.6" + } + }, + "node_modules/mdast-builder": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/mdast-builder/-/mdast-builder-1.1.1.tgz", + "integrity": "sha512-a3KBk/LmYD6wKsWi8WJrGU/rXR4yuF4Men0JO0z6dSZCm5FrXXWTRDjqK0vGSqa+1M6p9edeuypZAZAzSehTUw==", + "dependencies": { + "@types/unist": "^2.0.3" + } + }, + "node_modules/mdast-comment-marker": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/mdast-comment-marker/-/mdast-comment-marker-2.1.2.tgz", + "integrity": "sha512-HED3ezseRVkBzZ0uK4q6RJMdufr/2p3VfVZstE3H1N9K8bwtspztWo6Xd7rEatuGNoCXaBna8oEqMwUn0Ve1bw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-mdx-expression": "^1.1.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-comment-marker/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-definitions": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/mdast-util-definitions/-/mdast-util-definitions-5.1.2.tgz", + "integrity": "sha512-8SVPMuHqlPME/z3gqVwWY4zVXn8lqKv/pAhC57FuJ40ImXyBpmO5ukh98zB2v7Blql2FiHjHv9LVztSIqjY+MA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "@types/unist": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-definitions/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-find-and-replace": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/mdast-util-find-and-replace/-/mdast-util-find-and-replace-3.0.0.tgz", + "integrity": "sha512-8wLPIKAvGdA5jgkI8AYKfSorV3og3vE6HA+gKeKEZydbi1EtUu2g4XCxIBj3R+AsFqY/uRtoYbH30tiWsFKkBQ==", + "dependencies": { + "@types/mdast": "^4.0.0", + "escape-string-regexp": "^5.0.0", + "unist-util-is": "^6.0.0", + "unist-util-visit-parents": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-find-and-replace/node_modules/escape-string-regexp": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-5.0.0.tgz", + "integrity": "sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/mdast-util-from-markdown": { + "version": "1.3.1", + "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-1.3.1.tgz", + "integrity": "sha512-4xTO/M8c82qBcnQc1tgpNtubGUW/Y1tBQ1B0i5CtSoelOLKFYlElIr3bvgREYYO5iRqbMY1YuqZng0GVOI8Qww==", + "dependencies": { + "@types/mdast": "^3.0.0", + "@types/unist": "^2.0.0", + "decode-named-character-reference": "^1.0.0", + "mdast-util-to-string": "^3.1.0", + "micromark": "^3.0.0", + "micromark-util-decode-numeric-character-reference": "^1.0.0", + "micromark-util-decode-string": "^1.0.0", + "micromark-util-normalize-identifier": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "unist-util-stringify-position": "^3.0.0", + "uvu": "^0.5.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-from-markdown/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-from-markdown/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-2.0.2.tgz", + "integrity": "sha512-qvZ608nBppZ4icQlhQQIAdc6S3Ffj9RGmzwUKUWuEICFnd1LVkN3EktF7ZHAgfcEdvZB5owU9tQgt99e2TlLjg==", + "dependencies": { + "mdast-util-from-markdown": "^1.0.0", + "mdast-util-gfm-autolink-literal": "^1.0.0", + "mdast-util-gfm-footnote": "^1.0.0", + "mdast-util-gfm-strikethrough": "^1.0.0", + "mdast-util-gfm-table": "^1.0.0", + "mdast-util-gfm-task-list-item": "^1.0.0", + "mdast-util-to-markdown": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-autolink-literal": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-autolink-literal/-/mdast-util-gfm-autolink-literal-1.0.3.tgz", + "integrity": "sha512-My8KJ57FYEy2W2LyNom4n3E7hKTuQk/0SES0u16tjA9Z3oFkF4RrC/hPAPgjlSpezsOvI8ObcXcElo92wn5IGA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "ccount": "^2.0.0", + "mdast-util-find-and-replace": "^2.0.0", + "micromark-util-character": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-autolink-literal/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-gfm-autolink-literal/node_modules/escape-string-regexp": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-5.0.0.tgz", + "integrity": "sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/mdast-util-gfm-autolink-literal/node_modules/mdast-util-find-and-replace": { + "version": "2.2.2", + "resolved": "https://registry.npmjs.org/mdast-util-find-and-replace/-/mdast-util-find-and-replace-2.2.2.tgz", + "integrity": "sha512-MTtdFRz/eMDHXzeK6W3dO7mXUlF82Gom4y0oOgvHhh/HXZAGvIQDUvQ0SuUx+j2tv44b8xTHOm8K/9OoRFnXKw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "escape-string-regexp": "^5.0.0", + "unist-util-is": "^5.0.0", + "unist-util-visit-parents": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-autolink-literal/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-autolink-literal/node_modules/unist-util-visit-parents": { + "version": "5.1.3", + "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-5.1.3.tgz", + "integrity": "sha512-x6+y8g7wWMyQhL1iZfhIPhDAs7Xwbn9nRosDXl7qoPTSCy0yNxnKc+hWokFifWQIDGi154rdUqKvbCa4+1kLhg==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-footnote": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-1.0.2.tgz", + "integrity": "sha512-56D19KOGbE00uKVj3sgIykpwKL179QsVFwx/DCW0u/0+URsryacI4MAdNJl0dh+u2PSsD9FtxPFbHCzJ78qJFQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-markdown": "^1.3.0", + "micromark-util-normalize-identifier": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-footnote/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-gfm-strikethrough": { + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-strikethrough/-/mdast-util-gfm-strikethrough-1.0.3.tgz", + "integrity": "sha512-DAPhYzTYrRcXdMjUtUjKvW9z/FNAMTdU0ORyMcbmkwYNbKocDpdk+PX1L1dQgOID/+vVs1uBQ7ElrBQfZ0cuiQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-markdown": "^1.3.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-strikethrough/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-gfm-table": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-table/-/mdast-util-gfm-table-1.0.7.tgz", + "integrity": "sha512-jjcpmNnQvrmN5Vx7y7lEc2iIOEytYv7rTvu+MeyAsSHTASGCCRA79Igg2uKssgOs1i1po8s3plW0sTu1wkkLGg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "markdown-table": "^3.0.0", + "mdast-util-from-markdown": "^1.0.0", + "mdast-util-to-markdown": "^1.3.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-table/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-gfm-task-list-item": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-task-list-item/-/mdast-util-gfm-task-list-item-1.0.2.tgz", + "integrity": "sha512-PFTA1gzfp1B1UaiJVyhJZA1rm0+Tzn690frc/L8vNX1Jop4STZgOE6bxUhnzdVSB+vm2GU1tIsuQcA9bxTQpMQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-markdown": "^1.3.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-gfm-task-list-item/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-heading-style": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/mdast-util-heading-style/-/mdast-util-heading-style-2.0.1.tgz", + "integrity": "sha512-0L5rthU4xKDVbw+UQ7D8Y8xOEsX4JXZvemWoEAsL+WAaeSH+TvVVwFnTb3G/OrjyP4VYQULoNWU+PdZfkmNu4A==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-heading-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-mdx-expression": { + "version": "1.3.2", + "resolved": "https://registry.npmjs.org/mdast-util-mdx-expression/-/mdast-util-mdx-expression-1.3.2.tgz", + "integrity": "sha512-xIPmR5ReJDu/DHH1OoIT1HkuybIfRGYRywC+gJtI7qHjCJp/M9jrmBEJW22O8lskDWm562BX2W8TiAwRTb0rKA==", + "dependencies": { + "@types/estree-jsx": "^1.0.0", + "@types/hast": "^2.0.0", + "@types/mdast": "^3.0.0", + "mdast-util-from-markdown": "^1.0.0", + "mdast-util-to-markdown": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-mdx-expression/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-phrasing": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/mdast-util-phrasing/-/mdast-util-phrasing-3.0.1.tgz", + "integrity": "sha512-WmI1gTXUBJo4/ZmSk79Wcb2HcjPJBzM1nlI/OUWA8yk2X9ik3ffNbBGsU+09BFmXaL1IBb9fiuvq6/KMiNycSg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-phrasing/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-phrasing/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-to-hast": { + "version": "12.3.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-12.3.0.tgz", + "integrity": "sha512-pits93r8PhnIoU4Vy9bjW39M2jJ6/tdHyja9rrot9uujkN7UTU9SDnE6WNJz/IGyQk3XHX6yNNtrBH6cQzm8Hw==", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/mdast": "^3.0.0", + "mdast-util-definitions": "^5.0.0", + "micromark-util-sanitize-uri": "^1.1.0", + "trim-lines": "^3.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-to-hast/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-to-markdown": { + "version": "1.5.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-1.5.0.tgz", + "integrity": "sha512-bbv7TPv/WC49thZPg3jXuqzuvI45IL2EVAr/KxF0BSdHsU0ceFHOmwQn6evxAh1GaoK/6GQ1wp4R4oW2+LFL/A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "@types/unist": "^2.0.0", + "longest-streak": "^3.0.0", + "mdast-util-phrasing": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "micromark-util-decode-string": "^1.0.0", + "unist-util-visit": "^4.0.0", + "zwitch": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-to-markdown/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/mdast-util-to-markdown/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/mdast-util-to-string": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-4.0.0.tgz", + "integrity": "sha512-0H44vDimn51F0YwvxSJSm0eCDOJTRlmN0R1yBh4HLj9wiV1Dn0QoXGbvFAWj2hSItVTlCmBF1hqKlIyUBVFLPg==", + "dependencies": { + "@types/mdast": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/micromark/-/micromark-3.2.0.tgz", + "integrity": "sha512-uD66tJj54JLYq0De10AhWycZWGQNUvDI55xPgk2sQM5kn1JYlhbCMTtEeT27+vAhW2FBQxLlOmS3pmA7/2z4aA==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "@types/debug": "^4.0.0", + "debug": "^4.0.0", + "decode-named-character-reference": "^1.0.0", + "micromark-core-commonmark": "^1.0.1", + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-chunked": "^1.0.0", + "micromark-util-combine-extensions": "^1.0.0", + "micromark-util-decode-numeric-character-reference": "^1.0.0", + "micromark-util-encode": "^1.0.0", + "micromark-util-normalize-identifier": "^1.0.0", + "micromark-util-resolve-all": "^1.0.0", + "micromark-util-sanitize-uri": "^1.0.0", + "micromark-util-subtokenize": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.1", + "uvu": "^0.5.0" + } + }, + "node_modules/micromark-core-commonmark": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-1.1.0.tgz", + "integrity": "sha512-BgHO1aRbolh2hcrzL2d1La37V0Aoz73ymF8rAcKnohLy93titmv62E0gP8Hrx9PKcKrqCZ1BbLGbP3bEhoXYlw==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "decode-named-character-reference": "^1.0.0", + "micromark-factory-destination": "^1.0.0", + "micromark-factory-label": "^1.0.0", + "micromark-factory-space": "^1.0.0", + "micromark-factory-title": "^1.0.0", + "micromark-factory-whitespace": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-chunked": "^1.0.0", + "micromark-util-classify-character": "^1.0.0", + "micromark-util-html-tag-name": "^1.0.0", + "micromark-util-normalize-identifier": "^1.0.0", + "micromark-util-resolve-all": "^1.0.0", + "micromark-util-subtokenize": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.1", + "uvu": "^0.5.0" + } + }, + "node_modules/micromark-extension-gfm": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm/-/micromark-extension-gfm-2.0.3.tgz", + "integrity": "sha512-vb9OoHqrhCmbRidQv/2+Bc6pkP0FrtlhurxZofvOEy5o8RtuuvTq+RQ1Vw5ZDNrVraQZu3HixESqbG+0iKk/MQ==", + "dependencies": { + "micromark-extension-gfm-autolink-literal": "^1.0.0", + "micromark-extension-gfm-footnote": "^1.0.0", + "micromark-extension-gfm-strikethrough": "^1.0.0", + "micromark-extension-gfm-table": "^1.0.0", + "micromark-extension-gfm-tagfilter": "^1.0.0", + "micromark-extension-gfm-task-list-item": "^1.0.0", + "micromark-util-combine-extensions": "^1.0.0", + "micromark-util-types": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-autolink-literal": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-autolink-literal/-/micromark-extension-gfm-autolink-literal-1.0.5.tgz", + "integrity": "sha512-z3wJSLrDf8kRDOh2qBtoTRD53vJ+CWIyo7uyZuxf/JAbNJjiHsOpG1y5wxk8drtv3ETAHutCu6N3thkOOgueWg==", + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-sanitize-uri": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-footnote": { + "version": "1.1.2", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-footnote/-/micromark-extension-gfm-footnote-1.1.2.tgz", + "integrity": "sha512-Yxn7z7SxgyGWRNa4wzf8AhYYWNrwl5q1Z8ii+CSTTIqVkmGZF1CElX2JI8g5yGoM3GAman9/PVCUFUSJ0kB/8Q==", + "dependencies": { + "micromark-core-commonmark": "^1.0.0", + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-normalize-identifier": "^1.0.0", + "micromark-util-sanitize-uri": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-strikethrough": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-strikethrough/-/micromark-extension-gfm-strikethrough-1.0.7.tgz", + "integrity": "sha512-sX0FawVE1o3abGk3vRjOH50L5TTLr3b5XMqnP9YDRb34M0v5OoZhG+OHFz1OffZ9dlwgpTBKaT4XW/AsUVnSDw==", + "dependencies": { + "micromark-util-chunked": "^1.0.0", + "micromark-util-classify-character": "^1.0.0", + "micromark-util-resolve-all": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-table": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-1.0.7.tgz", + "integrity": "sha512-3ZORTHtcSnMQEKtAOsBQ9/oHp9096pI/UvdPtN7ehKvrmZZ2+bbWhi0ln+I9drmwXMt5boocn6OlwQzNXeVeqw==", + "dependencies": { + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-tagfilter": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-tagfilter/-/micromark-extension-gfm-tagfilter-1.0.2.tgz", + "integrity": "sha512-5XWB9GbAUSHTn8VPU8/1DBXMuKYT5uOgEjJb8gN3mW0PNW5OPHpSdojoqf+iq1xo7vWzw/P8bAHY0n6ijpXF7g==", + "dependencies": { + "micromark-util-types": "^1.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-extension-gfm-task-list-item": { + "version": "1.0.5", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-task-list-item/-/micromark-extension-gfm-task-list-item-1.0.5.tgz", + "integrity": "sha512-RMFXl2uQ0pNQy6Lun2YBYT9g9INXtWJULgbt01D/x8/6yJ2qpKyzdZD3pi6UIkzF++Da49xAelVKUeUMqd5eIQ==", + "dependencies": { + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/micromark-factory-destination": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-1.1.0.tgz", + "integrity": "sha512-XaNDROBgx9SgSChd69pjiGKbV+nfHGDPVYFs5dOoDd7ZnMAE+Cuu91BCpsY8RT2NP9vo/B8pds2VQNCLiu0zhg==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-factory-label": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-1.1.0.tgz", + "integrity": "sha512-OLtyez4vZo/1NjxGhcpDSbHQ+m0IIGnT8BoPamh+7jVlzLJBH98zzuCoUeMxvM6WsNeh8wx8cKvqLiPHEACn0w==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + } + }, + "node_modules/micromark-factory-space": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-1.1.0.tgz", + "integrity": "sha512-cRzEj7c0OL4Mw2v6nwzttyOZe8XY/Z8G0rzmWQZTBi/jjwyw/U4uqKtUORXQrR5bAZZnbTI/feRV/R7hc4jQYQ==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-factory-title": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-1.1.0.tgz", + "integrity": "sha512-J7n9R3vMmgjDOCY8NPw55jiyaQnH5kBdV2/UXCtZIpnHH3P6nHUKaH7XXEYuWwx/xUJcawa8plLBEjMPU24HzQ==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-factory-whitespace": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-1.1.0.tgz", + "integrity": "sha512-v2WlmiymVSp5oMg+1Q0N1Lxmt6pMhIHD457whWM7/GUlEks1hI9xj5w3zbc4uuMKXGisksZk8DzP2UyGbGqNsQ==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-factory-space": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-util-character": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-1.2.0.tgz", + "integrity": "sha512-lXraTwcX3yH/vMDaFWCQJP1uIszLVebzUa3ZHdrgxr7KEU/9mL4mVgCpGbyhvNLNlauROiNUq7WN5u7ndbY6xg==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-util-chunked": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-1.1.0.tgz", + "integrity": "sha512-Ye01HXpkZPNcV6FiyoW2fGZDUw4Yc7vT0E9Sad83+bEDiCJ1uXu0S3mr8WLpsz3HaG3x2q0HM6CTuPdcZcluFQ==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-symbol": "^1.0.0" + } + }, + "node_modules/micromark-util-classify-character": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-1.1.0.tgz", + "integrity": "sha512-SL0wLxtKSnklKSUplok1WQFoGhUdWYKggKUiqhX+Swala+BtptGCu5iPRc+xvzJ4PXE/hwM3FNXsfEVgoZsWbw==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-util-combine-extensions": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-1.1.0.tgz", + "integrity": "sha512-Q20sp4mfNf9yEqDL50WwuWZHUrCO4fEyeDCnMGmG5Pr0Cz15Uo7KBs6jq+dq0EgX4DPwwrh9m0X+zPV1ypFvUA==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-chunked": "^1.0.0", + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-util-decode-numeric-character-reference": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-1.1.0.tgz", + "integrity": "sha512-m9V0ExGv0jB1OT21mrWcuf4QhP46pH1KkfWy9ZEezqHKAxkj4mPCy3nIH1rkbdMlChLHX531eOrymlwyZIf2iw==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-symbol": "^1.0.0" + } + }, + "node_modules/micromark-util-decode-string": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-1.1.0.tgz", + "integrity": "sha512-YphLGCK8gM1tG1bd54azwyrQRjCFcmgj2S2GoJDNnh4vYtnL38JS8M4gpxzOPNyHdNEpheyWXCTnnTDY3N+NVQ==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "decode-named-character-reference": "^1.0.0", + "micromark-util-character": "^1.0.0", + "micromark-util-decode-numeric-character-reference": "^1.0.0", + "micromark-util-symbol": "^1.0.0" + } + }, + "node_modules/micromark-util-encode": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-1.1.0.tgz", + "integrity": "sha512-EuEzTWSTAj9PA5GOAs992GzNh2dGQO52UvAbtSOMvXTxv3Criqb6IOzJUBCmEqrrXSblJIJBbFFv6zPxpreiJw==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ] + }, + "node_modules/micromark-util-html-tag-name": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-1.2.0.tgz", + "integrity": "sha512-VTQzcuQgFUD7yYztuQFKXT49KghjtETQ+Wv/zUjGSGBioZnkA4P1XXZPT1FHeJA6RwRXSF47yvJ1tsJdoxwO+Q==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ] + }, + "node_modules/micromark-util-normalize-identifier": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-1.1.0.tgz", + "integrity": "sha512-N+w5vhqrBihhjdpM8+5Xsxy71QWqGn7HYNUvch71iV2PM7+E3uWGox1Qp90loa1ephtCxG2ftRV/Conitc6P2Q==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-symbol": "^1.0.0" + } + }, + "node_modules/micromark-util-resolve-all": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-1.1.0.tgz", + "integrity": "sha512-b/G6BTMSg+bX+xVCshPTPyAu2tmA0E4X98NSR7eIbeC6ycCqCeE7wjfDIgzEbkzdEVJXRtOG4FbEm/uGbCRouA==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-types": "^1.0.0" + } + }, + "node_modules/micromark-util-sanitize-uri": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-1.2.0.tgz", + "integrity": "sha512-QO4GXv0XZfWey4pYFndLUKEAktKkG5kZTdUNaTAkzbuJxn2tNBOr+QtxR2XpWaMhbImT2dPzyLrPXLlPhph34A==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-character": "^1.0.0", + "micromark-util-encode": "^1.0.0", + "micromark-util-symbol": "^1.0.0" + } + }, + "node_modules/micromark-util-subtokenize": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-1.1.0.tgz", + "integrity": "sha512-kUQHyzRoxvZO2PuLzMt2P/dwVsTiivCK8icYTeR+3WgbuPqfHgPPy7nFKbeqRivBvn/3N3GBiNC+JRTMSxEC7A==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ], + "dependencies": { + "micromark-util-chunked": "^1.0.0", + "micromark-util-symbol": "^1.0.0", + "micromark-util-types": "^1.0.0", + "uvu": "^0.5.0" + } + }, + "node_modules/micromark-util-symbol": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-1.1.0.tgz", + "integrity": "sha512-uEjpEYY6KMs1g7QfJ2eX1SQEV+ZT4rUD3UcF6l57acZvLNK7PBZL+ty82Z1qhK1/yXIY4bdx04FKMgR0g4IAag==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ] + }, + "node_modules/micromark-util-types": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-1.1.0.tgz", + "integrity": "sha512-ukRBgie8TIAcacscVHSiddHjO4k/q3pnedmzMQ4iwDcK0FtFCohKOlFbaOL/mPgfnPsL3C1ZyxJa4sbWrBl3jg==", + "funding": [ + { + "type": "GitHub Sponsors", + "url": "https://github.com/sponsors/unifiedjs" + }, + { + "type": "OpenCollective", + "url": "https://opencollective.com/unified" + } + ] + }, + "node_modules/mimic-fn": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/mimic-fn/-/mimic-fn-2.1.0.tgz", + "integrity": "sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==", + "engines": { + "node": ">=6" + } + }, + "node_modules/minimatch": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, + "dependencies": { + "brace-expansion": "^1.1.7" + }, + "engines": { + "node": "*" + } + }, + "node_modules/minimist": { + "version": "1.2.8", + "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.8.tgz", + "integrity": "sha512-2yyAR8qBkN3YuheJanUpWC5U3bb5osDywNB8RzDVlDwDHbocAJveqqj1u8+SVD7jkWT4yvsHCpWqqWqAxb0zCA==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/minipass": { + "version": "7.0.3", + "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.0.3.tgz", + "integrity": "sha512-LhbbwCfz3vsb12j/WkWQPZfKTsgqIe1Nf/ti1pKjYESGLHIVjWU96G9/ljLH4F9mWNVhlQOm0VySdAWzf05dpg==", + "engines": { + "node": ">=16 || 14 >=14.17" + } + }, + "node_modules/mri": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/mri/-/mri-1.2.0.tgz", + "integrity": "sha512-tzzskb3bG8LvYGFF/mDTpq3jpI6Q9wc3LEmBaghu+DdCssd1FakN7Bc0hVNmEyGq1bq3RgfkCb3cmQLpNPOroA==", + "engines": { + "node": ">=4" + } + }, + "node_modules/ms": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", + "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" + }, + "node_modules/mute-stream": { + "version": "0.0.8", + "resolved": "https://registry.npmjs.org/mute-stream/-/mute-stream-0.0.8.tgz", + "integrity": "sha512-nnbWWOkoWyUsTjKrhgD0dcz22mdkSnpYqbEjIm2nhwhuxlSkpywJmBo8h0ZqJdkp73mb90SssHkN4rsRaBAfAA==" + }, + "node_modules/natural-compare": { + "version": "1.4.0", + "resolved": "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz", + "integrity": "sha512-OWND8ei3VtNC9h7V60qff3SVobHr996CTwgxubgyQYEpg290h9J0buyECNNJexkFm5sOajh5G116RYA1c8ZMSw==", + "dev": true + }, + "node_modules/nopt": { + "version": "7.2.0", + "resolved": "https://registry.npmjs.org/nopt/-/nopt-7.2.0.tgz", + "integrity": "sha512-CVDtwCdhYIvnAzFoJ6NJ6dX3oga9/HyciQDnG1vQDjSLMeKLJ4A93ZqYKDrgYSr1FBY5/hMYC+2VCi24pgpkGA==", + "dependencies": { + "abbrev": "^2.0.0" + }, + "bin": { + "nopt": "bin/nopt.js" + }, + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/normalize-path": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", + "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==", + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/npm-normalize-package-bin": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/npm-normalize-package-bin/-/npm-normalize-package-bin-3.0.1.tgz", + "integrity": "sha512-dMxCf+zZ+3zeQZXKxmyuCKlIDPGuv8EF940xbkC4kQVDTtqoh6rJFO+JTKSA6/Rwi0getWmtuy4Itup0AMcaDQ==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/nth-check": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-2.1.1.tgz", + "integrity": "sha512-lqjrjmaOoAnWfMmBPL+XNnynZh2+swxiX3WUE0s4yEHI6m+AwrK2UZOimIRl3X/4QctVqS8AiZjFqyOGrMXb/w==", + "dependencies": { + "boolbase": "^1.0.0" + }, + "funding": { + "url": "https://github.com/fb55/nth-check?sponsor=1" + } + }, + "node_modules/object-inspect": { + "version": "1.12.3", + "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.12.3.tgz", + "integrity": "sha512-geUvdk7c+eizMNUDkRpW1wJwgfOiOeHbxBR/hLXK1aT6zmVSO0jsQcs7fj6MGw89jC/cjGfLcNOrtMYtGqm81g==", + "dev": true, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/object-keys": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/object-keys/-/object-keys-1.1.1.tgz", + "integrity": "sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==", + "dev": true, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/object.assign": { + "version": "4.1.4", + "resolved": "https://registry.npmjs.org/object.assign/-/object.assign-4.1.4.tgz", + "integrity": "sha512-1mxKf0e58bvyjSCtKYY4sRe9itRk3PJpquJOjeIkz885CczcI4IvJJDLPS72oowuSh+pBxUFROpX+TU++hxhZQ==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "has-symbols": "^1.0.3", + "object-keys": "^1.1.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/object.fromentries": { + "version": "2.0.6", + "resolved": "https://registry.npmjs.org/object.fromentries/-/object.fromentries-2.0.6.tgz", + "integrity": "sha512-VciD13dswC4j1Xt5394WR4MzmAQmlgN72phd/riNp9vtD7tp4QQWJ0R4wvclXcafgcYK8veHRed2W6XeGBvcfg==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/object.groupby": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/object.groupby/-/object.groupby-1.0.0.tgz", + "integrity": "sha512-70MWG6NfRH9GnbZOikuhPPYzpUpof9iW2J9E4dW7FXTqPNb6rllE6u39SKwwiNh8lCwX3DDb5OgcKGiEBrTTyw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.2.0", + "es-abstract": "^1.21.2", + "get-intrinsic": "^1.2.1" + } + }, + "node_modules/object.values": { + "version": "1.1.6", + "resolved": "https://registry.npmjs.org/object.values/-/object.values-1.1.6.tgz", + "integrity": "sha512-FVVTkD1vENCsAcwNs9k6jea2uHC/X0+JcjG8YA60FN5CMaJmG95wT9jek/xX9nornqGRrBkKtzuAu2wuHpKqvw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/once": { + "version": "1.4.0", + "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz", + "integrity": "sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==", + "dependencies": { + "wrappy": "1" + } + }, + "node_modules/onetime": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/onetime/-/onetime-5.1.2.tgz", + "integrity": "sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==", + "dependencies": { + "mimic-fn": "^2.1.0" + }, + "engines": { + "node": ">=6" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/optionator": { + "version": "0.9.3", + "resolved": "https://registry.npmjs.org/optionator/-/optionator-0.9.3.tgz", + "integrity": "sha512-JjCoypp+jKn1ttEFExxhetCKeJt9zhAgAve5FXHixTvFDW/5aEktX9bufBKLRRMdU7bNtpLfcGu94B3cdEJgjg==", + "dev": true, + "dependencies": { + "@aashutoshrathi/word-wrap": "^1.2.3", + "deep-is": "^0.1.3", + "fast-levenshtein": "^2.0.6", + "levn": "^0.4.1", + "prelude-ls": "^1.2.1", + "type-check": "^0.4.0" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/ora": { + "version": "5.4.1", + "resolved": "https://registry.npmjs.org/ora/-/ora-5.4.1.tgz", + "integrity": "sha512-5b6Y85tPxZZ7QytO+BQzysW31HJku27cRIlkbAXaNx+BdcVi+LlRFmVXzeF6a7JCwJpyw5c4b+YSVImQIrBpuQ==", + "dependencies": { + "bl": "^4.1.0", + "chalk": "^4.1.0", + "cli-cursor": "^3.1.0", + "cli-spinners": "^2.5.0", + "is-interactive": "^1.0.0", + "is-unicode-supported": "^0.1.0", + "log-symbols": "^4.1.0", + "strip-ansi": "^6.0.0", + "wcwidth": "^1.0.1" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/os-tmpdir": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/os-tmpdir/-/os-tmpdir-1.0.2.tgz", + "integrity": "sha512-D2FR03Vir7FIu45XBY20mTb+/ZSWB00sjU9jdQXt83gDrI4Ztz5Fs7/yy74g2N5SVQY4xY1qDr4rNddwYRVX0g==", + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/p-limit": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/p-limit/-/p-limit-3.1.0.tgz", + "integrity": "sha512-TYOanM3wGwNGsZN2cVTYPArw454xnXj5qmWF1bEoAc4+cU/ol7GVh7odevjp1FNHduHc3KZMcFduxU5Xc6uJRQ==", + "dev": true, + "dependencies": { + "yocto-queue": "^0.1.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/p-locate": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-5.0.0.tgz", + "integrity": "sha512-LaNjtRWUBY++zB5nE/NwcaoMylSPk+S+ZHNB1TzdbMJMny6dynpAGt7X/tl/QYq3TIeE6nxHppbo2LGymrG5Pw==", + "dev": true, + "dependencies": { + "p-limit": "^3.0.2" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/parent-module": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/parent-module/-/parent-module-1.0.1.tgz", + "integrity": "sha512-GQ2EWRpQV8/o+Aw8YqtfZZPfNRWZYkbidE9k5rpl/hC3vtHHBfGm2Ifi6qWV+coDGkrUKZAxE3Lot5kcsRlh+g==", + "dev": true, + "dependencies": { + "callsites": "^3.0.0" + }, + "engines": { + "node": ">=6" + } + }, + "node_modules/parse-json": { + "version": "6.0.2", + "resolved": "https://registry.npmjs.org/parse-json/-/parse-json-6.0.2.tgz", + "integrity": "sha512-SA5aMiaIjXkAiBrW/yPgLgQAQg42f7K3ACO+2l/zOvtQBwX58DMUsFJXelW2fx3yMBmWOVkR6j1MGsdSbCA4UA==", + "dependencies": { + "@babel/code-frame": "^7.16.0", + "error-ex": "^1.3.2", + "json-parse-even-better-errors": "^2.3.1", + "lines-and-columns": "^2.0.2" + }, + "engines": { + "node": "^12.20.0 || ^14.13.1 || >=16.0.0" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/parse5": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz", + "integrity": "sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==" + }, + "node_modules/parse5-htmlparser2-tree-adapter": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-7.0.0.tgz", + "integrity": "sha512-B77tOZrqqfUfnVcOrUvfdLbz4pu4RopLD/4vmu3HUPswwTA8OH0EMW9BlWR2B0RCoiZRAHEUu7IxeP1Pd1UU+g==", + "dependencies": { + "domhandler": "^5.0.2", + "parse5": "^7.0.0" + }, + "funding": { + "url": "https://github.com/inikulin/parse5?sponsor=1" + } + }, + "node_modules/parse5-htmlparser2-tree-adapter/node_modules/parse5": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.1.2.tgz", + "integrity": "sha512-Czj1WaSVpaoj0wbhMzLmWD69anp2WH7FXMB9n1Sy8/ZFF9jolSQVMu1Ij5WIyGmcBmhk7EOndpO4mIpihVqAXw==", + "dependencies": { + "entities": "^4.4.0" + }, + "funding": { + "url": "https://github.com/inikulin/parse5?sponsor=1" + } + }, + "node_modules/path-exists": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz", + "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==", + "dev": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/path-is-absolute": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz", + "integrity": "sha512-AVbw3UJ2e9bq64vSaS9Am0fje1Pa8pbGqTTsmXfaIiMpnr5DlDhfJOuLj9Sf95ZPVDAUerDfEk88MPmPe7UCQg==", + "dev": true, + "engines": { + "node": ">=0.10.0" + } + }, + "node_modules/path-key": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz", + "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==", + "engines": { + "node": ">=8" + } + }, + "node_modules/path-parse": { + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/path-parse/-/path-parse-1.0.7.tgz", + "integrity": "sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==", + "dev": true + }, + "node_modules/path-scurry": { + "version": "1.10.1", + "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.10.1.tgz", + "integrity": "sha512-MkhCqzzBEpPvxxQ71Md0b1Kk51W01lrYvlMzSUaIzNsODdd7mqhiimSZlr+VegAz5Z6Vzt9Xg2ttE//XBhH3EQ==", + "dependencies": { + "lru-cache": "^9.1.1 || ^10.0.0", + "minipass": "^5.0.0 || ^6.0.2 || ^7.0.0" + }, + "engines": { + "node": ">=16 || 14 >=14.17" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/path-scurry/node_modules/lru-cache": { + "version": "10.0.1", + "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.0.1.tgz", + "integrity": "sha512-IJ4uwUTi2qCccrioU6g9g/5rvvVl13bsdczUUcqbciD9iLr095yj8DQKdObriEvuNSx325N1rV1O0sJFszx75g==", + "engines": { + "node": "14 || >=16.14" + } + }, + "node_modules/picomatch": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", + "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "engines": { + "node": ">=8.6" + }, + "funding": { + "url": "https://github.com/sponsors/jonschlinkert" + } + }, + "node_modules/pluralize": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/pluralize/-/pluralize-8.0.0.tgz", + "integrity": "sha512-Nc3IT5yHzflTfbjgqWcCPpo7DaKy4FnpB0l/zCAW0Tc7jxAiuqSxHasntB3D7887LSrA93kDJ9IXovxJYxyLCA==", + "engines": { + "node": ">=4" + } + }, + "node_modules/prelude-ls": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.2.1.tgz", + "integrity": "sha512-vkcDPrRZo1QZLbn5RLGPpg/WmIQ65qoWWhcGKf/b5eplkkarX0m9z8ppCat4mlOqUsWpyNuYgO3VRyrYHSzX5g==", + "dev": true, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/proc-log": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/proc-log/-/proc-log-3.0.0.tgz", + "integrity": "sha512-++Vn7NS4Xf9NacaU9Xq3URUuqZETPsf8L4j5/ckhaRYsfPeRyzGw+iDjFhV/Jr3uNmTvvddEJFWh5R1gRgUH8A==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/property-information": { + "version": "6.2.0", + "resolved": "https://registry.npmjs.org/property-information/-/property-information-6.2.0.tgz", + "integrity": "sha512-kma4U7AFCTwpqq5twzC1YVIDXSqg6qQK6JN0smOw8fgRy1OkMi0CYSzFmsy6dnqSenamAtj0CyXMUJ1Mf6oROg==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/propose": { + "version": "0.0.5", + "resolved": "https://registry.npmjs.org/propose/-/propose-0.0.5.tgz", + "integrity": "sha512-Jary1vb+ap2DIwOGfyiadcK4x1Iu3pzpkDBy8tljFPmQvnc9ES3m1PMZOMiWOG50cfoAyYNtGeBzrp+Rlh4G9A==", + "dependencies": { + "levenshtein-edit-distance": "^1.0.0" + } + }, + "node_modules/punycode": { + "version": "2.3.0", + "resolved": "https://registry.npmjs.org/punycode/-/punycode-2.3.0.tgz", + "integrity": "sha512-rRV+zQD8tVFys26lAGR9WUuS4iUAngJScM+ZRSKtvl5tKeZ2t5bvdNFdNHBW9FWR4guGHlgmsZ1G7BSm2wTbuA==", + "dev": true, + "engines": { + "node": ">=6" + } + }, + "node_modules/queue-microtask": { + "version": "1.2.3", + "resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz", + "integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/read-package-json-fast": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/read-package-json-fast/-/read-package-json-fast-3.0.2.tgz", + "integrity": "sha512-0J+Msgym3vrLOUB3hzQCuZHII0xkNGCtz/HJH9xZshwv9DbDwkw1KaE3gx/e2J5rpEY5rtOy6cyhKOPrkP7FZw==", + "dependencies": { + "json-parse-even-better-errors": "^3.0.0", + "npm-normalize-package-bin": "^3.0.0" + }, + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/read-package-json-fast/node_modules/json-parse-even-better-errors": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-3.0.0.tgz", + "integrity": "sha512-iZbGHafX/59r39gPwVPRBGw0QQKnA7tte5pSMrhWOW7swGsVvVTjmfyAV9pNqk8YGT7tRCdxRu8uzcgZwoDooA==", + "engines": { + "node": "^14.17.0 || ^16.13.0 || >=18.0.0" + } + }, + "node_modules/readable-stream": { + "version": "3.6.2", + "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz", + "integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==", + "dependencies": { + "inherits": "^2.0.3", + "string_decoder": "^1.1.1", + "util-deprecate": "^1.0.1" + }, + "engines": { + "node": ">= 6" + } + }, + "node_modules/readdirp": { + "version": "3.6.0", + "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz", + "integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==", + "dependencies": { + "picomatch": "^2.2.1" + }, + "engines": { + "node": ">=8.10.0" + } + }, + "node_modules/regexp.prototype.flags": { + "version": "1.5.0", + "resolved": "https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.0.tgz", + "integrity": "sha512-0SutC3pNudRKgquxGoRGIz946MZVHqbNfPjBdxeOhBrdgDKlRoXmYLQN9xRbrR09ZXWeGAdPuif7egofn6v5LA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.2.0", + "functions-have-names": "^1.2.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/rehype-stringify": { + "version": "9.0.4", + "resolved": "https://registry.npmjs.org/rehype-stringify/-/rehype-stringify-9.0.4.tgz", + "integrity": "sha512-Uk5xu1YKdqobe5XpSskwPvo1XeHUUucWEQSl8hTrXt5selvca1e8K1EZ37E6YoZ4BT8BCqCdVfQW7OfHfthtVQ==", + "dependencies": { + "@types/hast": "^2.0.0", + "hast-util-to-html": "^8.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark": { + "version": "14.0.3", + "resolved": "https://registry.npmjs.org/remark/-/remark-14.0.3.tgz", + "integrity": "sha512-bfmJW1dmR2LvaMJuAnE88pZP9DktIFYXazkTfOIKZzi3Knk9lT0roItIA24ydOucI3bV/g/tXBA6hzqq3FV9Ew==", + "dependencies": { + "@types/mdast": "^3.0.0", + "remark-parse": "^10.0.0", + "remark-stringify": "^10.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-flexible-containers": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/remark-flexible-containers/-/remark-flexible-containers-1.0.6.tgz", + "integrity": "sha512-eMIcmaBwx+Fwvfe+43xbAlMlbrYD/EndjTf0xTv9dOECozHuCTyM5ZibcYaJFA7PCxCm3Q7kCPZQ5BGUr7rYpQ==", + "dependencies": { + "@types/mdast": "^3.0.11", + "unist-util-find-after": "^4.0.1", + "unist-util-find-between-all": "^1.0.4", + "unist-util-visit": "^4.0.0" + } + }, + "node_modules/remark-flexible-containers/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-gfm": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-gfm/-/remark-gfm-3.0.1.tgz", + "integrity": "sha512-lEFDoi2PICJyNrACFOfDD3JlLkuSbOa5Wd8EPt06HUdptv8Gn0bxYTdbU/XXQ3swAPkEaGxxPN9cbnMHvVu1Ig==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-gfm": "^2.0.0", + "micromark-extension-gfm": "^2.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-gfm/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-heading-id": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/remark-heading-id/-/remark-heading-id-1.0.0.tgz", + "integrity": "sha512-86QaOiL+8jTV9P5Y0S25kSIcykCd/XmnqiFltWZRWKHmsVT4sevN7QJnkpUjkCJUpIeWte/LYH7pVlCTGz89fw==", + "dependencies": { + "unist-util-visit": "^1.4.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/remark-heading-id/node_modules/unist-util-is": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-3.0.0.tgz", + "integrity": "sha512-sVZZX3+kspVNmLWBPAB6r+7D9ZgAFPNWm66f7YNb420RlQSbn+n8rG8dGZSkrER7ZIXGQYNm5pqC3v3HopH24A==" + }, + "node_modules/remark-heading-id/node_modules/unist-util-visit": { + "version": "1.4.1", + "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-1.4.1.tgz", + "integrity": "sha512-AvGNk7Bb//EmJZyhtRUnNMEpId/AZ5Ph/KUpTI09WHQuDZHKovQ1oEv3mfmKpWKtoMzyMC4GLBm1Zy5k12fjIw==", + "dependencies": { + "unist-util-visit-parents": "^2.0.0" + } + }, + "node_modules/remark-heading-id/node_modules/unist-util-visit-parents": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-2.1.2.tgz", + "integrity": "sha512-DyN5vD4NE3aSeB+PXYNKxzGsfocxp6asDc2XXE3b0ekO2BaRUpBicbbUygfSvYfUz1IkmjFR1YF7dPklraMZ2g==", + "dependencies": { + "unist-util-is": "^3.0.0" + } + }, + "node_modules/remark-lint": { + "version": "9.1.2", + "resolved": "https://registry.npmjs.org/remark-lint/-/remark-lint-9.1.2.tgz", + "integrity": "sha512-m9e/aPlh7tsvfJfj8tPxrQzD6oEdb9Foko+Ya/6OwUP9EoGMfehv1Qtv26W1DoH58Wn8rT8CD+KuprTWscMmIA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "remark-message-control": "^7.0.0", + "unified": "^10.1.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-blockquote-indentation": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-blockquote-indentation/-/remark-lint-blockquote-indentation-3.1.2.tgz", + "integrity": "sha512-5DOrFsZd5dXqA4p/VZvWSrqIWNFbBXjX7IV/FkVkxlNhNF/0FMf/4v8x1I2W3mzaZ7yDsWS/egpZnmligq1ckQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "pluralize": "^8.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-blockquote-indentation/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-code-block-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-code-block-style/-/remark-lint-code-block-style-3.1.2.tgz", + "integrity": "sha512-3wsWmzzdyEsB9sOzBOf46TSkwwVKXN2JpTEQb6feN0Tl6Vg75F7T9MHqMz7aqk/56bOXSxUzdpXDscGBhziLRA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-code-block-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-definition-case": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-definition-case/-/remark-lint-definition-case-3.1.2.tgz", + "integrity": "sha512-/VxucJKEFykOe2ILgi0LLia0RaSyOPQXpR+tuX4MK3iKxIm7aT2oINgR9ugLpI15xJ463LyTi5mXf+BGveXeWA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-definition-case/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-definition-spacing": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-definition-spacing/-/remark-lint-definition-spacing-3.1.2.tgz", + "integrity": "sha512-l058jAKfZfCOmlbIzoTll+CrZm9Bh42ZVCHcODPSZC8Yx4terCKgIoks+RWJDEdUbEw0YQoYvPc59ZVmp3BIew==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-definition-spacing/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-emphasis-marker": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-emphasis-marker/-/remark-lint-emphasis-marker-3.1.2.tgz", + "integrity": "sha512-hPZ8vxZrIfxmLA5B66bA8y3PdHjcCQuaLsySIqi5PM2DkpN6a7zAP3v1znyRSaYJ1ANVWcu00/0bNzuUjflGCA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-emphasis-marker/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-fenced-code-flag": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-flag/-/remark-lint-fenced-code-flag-3.1.2.tgz", + "integrity": "sha512-yh4m3dlPmRsqM/BFhpqHYfrmBvFQ+D5dZZKDDYP2rf3YEoXlEVt8T8lWQueTTSxcq6yXAqL/XQL/iqqUHlLcHw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-fenced-code-flag/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-fenced-code-marker": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-marker/-/remark-lint-fenced-code-marker-3.1.2.tgz", + "integrity": "sha512-6XNqjOuhT+0c7Q/22aCsMz61ne9g8HRpYF79EXQPdbzYa+PcfPXMiQKStONY3PfC8OE2/3WXI2zcs8w9x+8+VQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-fenced-code-marker/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-file-extension": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-file-extension/-/remark-lint-file-extension-2.1.2.tgz", + "integrity": "sha512-Nq54F5R7F1gyj/IMW6SvkAbVNrH+p38WK3//KCoZLDUYFrH0oXgXXFGHi9CT/O0VEopW+bWJfTn8YAJRs0qI5Q==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-file-extension/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-final-definition": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-final-definition/-/remark-lint-final-definition-3.1.2.tgz", + "integrity": "sha512-3O3JT6xqlrgq+UjhMPxshgMtwXn99w0BEO9JwbDls49N0XCu0n22Pq1n6X3tEVzskPLo3YYyVYfW2Z2C2rneKQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-final-definition/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-hard-break-spaces": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-hard-break-spaces/-/remark-lint-hard-break-spaces-3.1.2.tgz", + "integrity": "sha512-HaW0xsl3TI7VFAqGWWcZtPqyz0NWu19KKjSO7OGFTUJU4S9YiRnhIxmSFM0ZLSsVAynE+dhzVKa8U7dOpWDcOg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-hard-break-spaces/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-heading-increment": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-heading-increment/-/remark-lint-heading-increment-3.1.2.tgz", + "integrity": "sha512-+fMfZmFh6ie6MmbRCVW77Rha15zDmnHWKiA0Do08OTrfngPTv8ZKXYLmxhUpL+xV9ts9q+9Kz5rv0L4QD4sEwQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-heading-increment/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-heading-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-heading-style/-/remark-lint-heading-style-3.1.2.tgz", + "integrity": "sha512-0RkcRPV/H2bPFgeInzBkK1cWUwtFTm83I+Db/Z5tDY02GzKOosHLvxtJyj/1391/opAH1LYbHtHWffir99IUgw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-heading-style": "^2.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-heading-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-link-title-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-link-title-style/-/remark-lint-link-title-style-3.1.2.tgz", + "integrity": "sha512-if4MahYJVvQUWlrXDF8GSv4b9VtLSgMSDHeikQp1/hGYlihLl9uGw3nlL5Lf9DqTN0qaT6RPbXOjuuzHlk38sg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0", + "vfile-location": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-link-title-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-list-item-content-indent": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-content-indent/-/remark-lint-list-item-content-indent-3.1.2.tgz", + "integrity": "sha512-TB0pmrWiRaQW80Y/PILFQTnHDghRxXNzMwyawlP+DBF9gNom3pEBmb4ZlGQlN0aa3r8VWeIKdv1ylHrfXE0vqA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "pluralize": "^8.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-list-item-content-indent/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-list-item-indent": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-indent/-/remark-lint-list-item-indent-3.1.2.tgz", + "integrity": "sha512-tkrra1pxZVE4OVJGfN435u/v0ljruXU+dHzWiKDYeifquD4aWhJxvSApu7+FbE098D/4usVXgMxwFkNhrpZcSQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "pluralize": "^8.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-list-item-indent/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-list-item-spacing": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-spacing/-/remark-lint-list-item-spacing-4.1.2.tgz", + "integrity": "sha512-RHscGCa81PzcI09H0JAKXGyUiIMRTg5u4G8/p1zqnfEeOgG1R+87mLEJrOC9tUWGjuVoyd7T8Q2DMxg1Iep9ow==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-list-item-spacing/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-maximum-heading-length": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-maximum-heading-length/-/remark-lint-maximum-heading-length-3.1.2.tgz", + "integrity": "sha512-gkmZxjlzEmNjBRBwef0L/Qmoabxxof0mryOxWzRZSu1xz4Qsp+UFWMhiHGXbE9WJL6EBW8yNTOpgnNgUOzqDiQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-maximum-heading-length/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-maximum-heading-length/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-maximum-line-length": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/remark-lint-maximum-line-length/-/remark-lint-maximum-line-length-3.1.3.tgz", + "integrity": "sha512-TA7IE+0c8agRm1k7JZr7ZZFiL44JMBAj1KlMxSTACBuebdPJe7IPaLIQga10bnz75jfWMzSiRURMFHo4lt3kdw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-maximum-line-length/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-blockquote-without-marker": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-5.1.2.tgz", + "integrity": "sha512-QPbqsrt7EfpSWqTkZJ9tepabPIhBDlNqZkuxxMQYD0OQ2N+tHDUq3zE1JxI5ts1V9o/mWApgySocqGd3jlcKmQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0", + "vfile-location": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-blockquote-without-marker/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-consecutive-blank-lines": { + "version": "4.1.3", + "resolved": "https://registry.npmjs.org/remark-lint-no-consecutive-blank-lines/-/remark-lint-no-consecutive-blank-lines-4.1.3.tgz", + "integrity": "sha512-yU3jH6UMHvaxX3DPBen+7CoPiCcqJ4BeteyOKeKX+tKWCWKILpiz+TVToRbeLnWO4IvFNnSRFMSXmcWSDdbY4w==", + "dependencies": { + "@types/mdast": "^3.0.0", + "@types/unist": "^2.0.0", + "pluralize": "^8.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-consecutive-blank-lines/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-duplicate-headings": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-headings/-/remark-lint-no-duplicate-headings-3.1.2.tgz", + "integrity": "sha512-atBlykGOx9BhpXGp0BUMWxn/T89+hC0Gel8xOIMaFkDhRcLlLVt+/F/aJGhM2Sp0R9NTQ6ejn+JYMLl5Aw2Z+g==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-stringify-position": "^3.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-duplicate-headings/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-duplicate-headings/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-emphasis-as-heading": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-emphasis-as-heading/-/remark-lint-no-emphasis-as-heading-3.1.2.tgz", + "integrity": "sha512-2DDx0VkqSExR6oqBiQtOsmdDwT7f3hpnPwPvBCk7BDeDU53JWY1kBAkRObkEptgH3GfpwxIQymIdHXesBpAQAg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-emphasis-as-heading/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-file-name-articles": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-articles/-/remark-lint-no-file-name-articles-2.1.2.tgz", + "integrity": "sha512-kM4vwBkne7f9euDKsuyxTtrsiafjH+KOwu8ZmuSVWh5U+u0EMcPyN5fxfaQIW+5FkrJA1jwnRu7ciXJBJt74Og==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-file-name-articles/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-file-name-consecutive-dashes": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-consecutive-dashes/-/remark-lint-no-file-name-consecutive-dashes-2.1.2.tgz", + "integrity": "sha512-gw06jaaFwBR3s+3E2kJlv+E7rAzS7Nj+MFU7TViwbsYnR7PA96htLVDCjClyNUE7JHUNcv93HdLm8ykg8kRyNA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-file-name-consecutive-dashes/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-file-name-irregular-characters": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-irregular-characters/-/remark-lint-no-file-name-irregular-characters-2.1.2.tgz", + "integrity": "sha512-2tcqzLm39Jc4THNP2yvJruOz2HtV4yh+eePiySKmhfZk/6ifMyOF/wlKHKcswczSGE4InNTfxJnc/AoxOJEdkw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-file-name-irregular-characters/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-file-name-mixed-case": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-mixed-case/-/remark-lint-no-file-name-mixed-case-2.1.2.tgz", + "integrity": "sha512-0mTrjxBB4/0rV7sef+xjV5Aeb6LuW19X4QbNHW2RW7aMy+mtgJU03wdb8Y0LTnWVFHjUbc+iHrsFeCA/Pu1kew==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-file-name-mixed-case/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-file-name-outer-dashes": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-outer-dashes/-/remark-lint-no-file-name-outer-dashes-2.1.2.tgz", + "integrity": "sha512-VrbHg25Oo9k/bNbS7ye1X7F6ER4uZSubO+t5DHJ4WZ6iVbNtBar/JwzVelY1YxUAutv42OvHfuveh4vKlcNgVA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-file-name-outer-dashes/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-heading-punctuation": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-heading-punctuation/-/remark-lint-no-heading-punctuation-3.1.2.tgz", + "integrity": "sha512-KnvHEVB/DcxJOhUvVteiovAy1+32YY5Vm0UBJqYCFrrHnN/y9ETvOJzlxFy47TaB8x2UyncSEg2JuT66UL4ONQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-heading-punctuation/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-heading-punctuation/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-inline-padding": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-inline-padding/-/remark-lint-no-inline-padding-4.1.2.tgz", + "integrity": "sha512-dGyhWsiqCZS3Slob0EVBUfsFBbdpMIBCvb56LlCgaHbnLsnNYx8PpF/wA5CgsN8BXIbXfRpyPB5cIJwIq5taYg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-inline-padding/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-inline-padding/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-literal-urls": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-3.1.2.tgz", + "integrity": "sha512-4tV9JGLKxAMFSuWDMOqLozkFJ3HyRvhzgrPrxASoziaml23m7UXAozk5dkIrFny1cN2oG988Z8tORxX2FL1Ilw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-string": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-literal-urls/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-literal-urls/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-multiple-toplevel-headings": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-multiple-toplevel-headings/-/remark-lint-no-multiple-toplevel-headings-3.1.2.tgz", + "integrity": "sha512-9rJSsrwdzwKmtuloBjJobLzjGL7Lgtk3+vMNUyuH9z/nBfkUCN3qxn3Nt9AxL+wwSAsHV6e74W+W2S1ohBLt6A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-stringify-position": "^3.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-multiple-toplevel-headings/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-shell-dollars": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-shell-dollars/-/remark-lint-no-shell-dollars-3.1.2.tgz", + "integrity": "sha512-np2MDEhXHviXhbQFjnC1QYv5/fxCV1cIHfGMoJpqiW7Zcu/UGCOo5TE3XswZH4ukHZJ65c3X2A6qfLDW+ur3CQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-shell-dollars/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-shortcut-reference-image": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-image/-/remark-lint-no-shortcut-reference-image-3.1.2.tgz", + "integrity": "sha512-NX4XJFPyDeJJ77pmETxRj4oM/zayf7Lmn/O87HgExBkQIPz2NYbDeKD8QEyliLaV/oKA2rQufpzuFw55xa1Tww==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-shortcut-reference-image/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-shortcut-reference-link": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-link/-/remark-lint-no-shortcut-reference-link-3.1.2.tgz", + "integrity": "sha512-/9iPN7FLKaaIzw4tLWKu7Rx0wAP7E2EuzIeentQlkY0rO/mMHipmT3IlgiebsAInKagzTY6TNFoG1rq2VnaCcA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-shortcut-reference-link/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-no-table-indentation": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-no-table-indentation/-/remark-lint-no-table-indentation-4.1.2.tgz", + "integrity": "sha512-5lkO+Yrtni/CDMZi7mlwbB2zzRQLH94DesboXg51aO2UfZlSn5dZNhmN5wkyCU2AiApUhlFNbxfKMHOWFPLdog==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0", + "vfile-location": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-table-indentation/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-ordered-list-marker-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-style/-/remark-lint-ordered-list-marker-style-3.1.2.tgz", + "integrity": "sha512-62iVE/YQsA0Azaqt8yAJWPplWLS47kDLjXeC2PlRIAzCqbNt9qH3HId8vZ15QTSrp8rHmJwrCMdcqV6AZUi7gQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-ordered-list-marker-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-ordered-list-marker-value": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-value/-/remark-lint-ordered-list-marker-value-3.1.2.tgz", + "integrity": "sha512-kG08nhsFk8rhoXK5EeDN/wN28CxefraDud/MaZnji8LEyxF3HAkzFuETr9laOn8Ey+n8h/C0mpqAwUf4thyJ5g==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-ordered-list-marker-value/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-rule-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-rule-style/-/remark-lint-rule-style-3.1.2.tgz", + "integrity": "sha512-0CsX2XcX9pIhAP5N7Y8mhYXp3/Ld+NvxXY1p0LHAq0NZu17UsZLuegvx/s25uFbQs08DcmSqyKnepU9qGGqmTQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-rule-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-strong-marker": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-strong-marker/-/remark-lint-strong-marker-3.1.2.tgz", + "integrity": "sha512-U/g4wngmiI0Q6WBRQG6pZxnDS33Wt/0QYA3+KNFBDykoi1vXsDEorIqy3dEag9z6XHwcMvFDsff6VRUhaOJWQg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-strong-marker/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-table-cell-padding": { + "version": "4.1.3", + "resolved": "https://registry.npmjs.org/remark-lint-table-cell-padding/-/remark-lint-table-cell-padding-4.1.3.tgz", + "integrity": "sha512-N9xtnS6MG/H3srAMjqqaF26A7socr87pIgt64dr5rxoSbDRWRPChGQ8y7wKyV8VeyRNF37e3E5KB3bQVqjSYaQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "@types/unist": "^2.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-table-cell-padding/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-table-pipe-alignment": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/remark-lint-table-pipe-alignment/-/remark-lint-table-pipe-alignment-3.1.3.tgz", + "integrity": "sha512-bnE8WrB4kSrN+Yr+xN2GHWVgGukeSFU43qPMrpCzTyOSbzep366wORlFKqZmyFPEkIZ/uAUFS0Qm9DND66Yz/A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-table-pipe-alignment/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-table-pipes": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-table-pipes/-/remark-lint-table-pipes-4.1.2.tgz", + "integrity": "sha512-Ex2cJDXA0hdD9CC5Nu0p3K5LP+AhzPvk4sIOSbevCTSRyCS/SkNk4CQ6pwWBxuPVuHQUkqXkT8lgu8wwr/9A3A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-table-pipes/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint-unordered-list-marker-style": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/remark-lint-unordered-list-marker-style/-/remark-lint-unordered-list-marker-style-3.1.2.tgz", + "integrity": "sha512-JFiyB4ZprJGGndCaFB8FssXd48m4Kh+CUqzNgu3lBLEiW8dEAGRlD9M2AzyyA+Q29WJP/FntDCbP22DeON91UA==", + "dependencies": { + "@types/mdast": "^3.0.0", + "unified": "^10.0.0", + "unified-lint-rule": "^2.0.0", + "unist-util-generated": "^2.0.0", + "unist-util-position": "^4.0.0", + "unist-util-visit": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-unordered-list-marker-style/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-lint/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-message-control": { + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/remark-message-control/-/remark-message-control-7.1.1.tgz", + "integrity": "sha512-xKRWl1NTBOKed0oEtCd8BUfH5m4s8WXxFFSoo7uUwx6GW/qdCy4zov5LfPyw7emantDmhfWn5PdIZgcbVcWMDQ==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-comment-marker": "^2.0.0", + "unified": "^10.0.0", + "unified-message-control": "^4.0.0", + "vfile": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-message-control/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-parse": { + "version": "10.0.2", + "resolved": "https://registry.npmjs.org/remark-parse/-/remark-parse-10.0.2.tgz", + "integrity": "sha512-3ydxgHa/ZQzG8LvC7jTXccARYDcRld3VfcgIIFs7bI6vbRSxJJmzgLEIIoYKyrfhaY+ujuWaf/PJiMZXoiCXgw==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-from-markdown": "^1.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-parse/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-preset-lint-markdown-style-guide": { + "version": "5.1.3", + "resolved": "https://registry.npmjs.org/remark-preset-lint-markdown-style-guide/-/remark-preset-lint-markdown-style-guide-5.1.3.tgz", + "integrity": "sha512-4zNSPoiwAh4LJCbXh2U8Q9SFUIMw0MwsYJWTXHNiD0bGIUMWYU8ATLzDpWqCkzra6Ih7rLZuqB8tQIlipcM4Hg==", + "dependencies": { + "@types/mdast": "^3.0.0", + "remark-lint": "^9.0.0", + "remark-lint-blockquote-indentation": "^3.0.0", + "remark-lint-code-block-style": "^3.0.0", + "remark-lint-definition-case": "^3.0.0", + "remark-lint-definition-spacing": "^3.0.0", + "remark-lint-emphasis-marker": "^3.0.0", + "remark-lint-fenced-code-flag": "^3.0.0", + "remark-lint-fenced-code-marker": "^3.0.0", + "remark-lint-file-extension": "^2.0.0", + "remark-lint-final-definition": "^3.0.0", + "remark-lint-hard-break-spaces": "^3.0.0", + "remark-lint-heading-increment": "^3.0.0", + "remark-lint-heading-style": "^3.0.0", + "remark-lint-link-title-style": "^3.0.0", + "remark-lint-list-item-content-indent": "^3.0.0", + "remark-lint-list-item-indent": "^3.0.0", + "remark-lint-list-item-spacing": "^4.0.0", + "remark-lint-maximum-heading-length": "^3.0.0", + "remark-lint-maximum-line-length": "^3.0.0", + "remark-lint-no-blockquote-without-marker": "^5.0.0", + "remark-lint-no-consecutive-blank-lines": "^4.0.0", + "remark-lint-no-duplicate-headings": "^3.0.0", + "remark-lint-no-emphasis-as-heading": "^3.0.0", + "remark-lint-no-file-name-articles": "^2.0.0", + "remark-lint-no-file-name-consecutive-dashes": "^2.0.0", + "remark-lint-no-file-name-irregular-characters": "^2.0.0", + "remark-lint-no-file-name-mixed-case": "^2.0.0", + "remark-lint-no-file-name-outer-dashes": "^2.0.0", + "remark-lint-no-heading-punctuation": "^3.0.0", + "remark-lint-no-inline-padding": "^4.0.0", + "remark-lint-no-literal-urls": "^3.0.0", + "remark-lint-no-multiple-toplevel-headings": "^3.0.0", + "remark-lint-no-shell-dollars": "^3.0.0", + "remark-lint-no-shortcut-reference-image": "^3.0.0", + "remark-lint-no-shortcut-reference-link": "^3.0.0", + "remark-lint-no-table-indentation": "^4.0.0", + "remark-lint-ordered-list-marker-style": "^3.0.0", + "remark-lint-ordered-list-marker-value": "^3.0.0", + "remark-lint-rule-style": "^3.0.0", + "remark-lint-strong-marker": "^3.0.0", + "remark-lint-table-cell-padding": "^4.0.0", + "remark-lint-table-pipe-alignment": "^3.0.0", + "remark-lint-table-pipes": "^4.0.0", + "remark-lint-unordered-list-marker-style": "^3.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-preset-lint-markdown-style-guide/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-rehype": { + "version": "10.1.0", + "resolved": "https://registry.npmjs.org/remark-rehype/-/remark-rehype-10.1.0.tgz", + "integrity": "sha512-EFmR5zppdBp0WQeDVZ/b66CWJipB2q2VLNFMabzDSGR66Z2fQii83G5gTBbgGEnEEA0QRussvrFHxk1HWGJskw==", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/mdast": "^3.0.0", + "mdast-util-to-hast": "^12.1.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-rehype/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-stringify": { + "version": "10.0.3", + "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-10.0.3.tgz", + "integrity": "sha512-koyOzCMYoUHudypbj4XpnAKFbkddRMYZHwghnxd7ue5210WzGw6kOBwauJTRUMq16jsovXx8dYNvSSWP89kZ3A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "mdast-util-to-markdown": "^1.0.0", + "unified": "^10.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-stringify/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-torchlight": { + "version": "0.0.5", + "resolved": "https://registry.npmjs.org/remark-torchlight/-/remark-torchlight-0.0.5.tgz", + "integrity": "sha512-aFnnUfbIGYFYr1HQDT8AVHBVsRRswLBdOM4ht9YB8e+gyV9UKN64b9i7xwRqWu78bzXTmxhqcQxnIaVNQO4iWA==", + "dependencies": { + "@torchlight-api/torchlight-cli": "^0.1.7", + "hast-util-from-parse5": "^7.1.0", + "parse5": "^6.0.1", + "unist-util-map": "^3.0.0" + } + }, + "node_modules/remark-validate-links": { + "version": "12.1.1", + "resolved": "https://registry.npmjs.org/remark-validate-links/-/remark-validate-links-12.1.1.tgz", + "integrity": "sha512-nk/CkcZ3u8QntoMCqZ+JzUzFub36E+mNFMMbYqqN+yQViUHbRLqirCG1qOI4E38RyKZ8abjFUv0JGB7skKa41A==", + "dependencies": { + "@types/mdast": "^3.0.0", + "github-slugger": "^2.0.0", + "hosted-git-info": "^6.0.0", + "mdast-util-to-string": "^3.2.0", + "propose": "0.0.5", + "to-vfile": "^7.0.0", + "trough": "^2.0.0", + "unified": "^10.0.0", + "unified-engine": "^10.0.1", + "unist-util-visit": "^4.0.0", + "vfile": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-validate-links/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-validate-links/node_modules/mdast-util-to-string": { + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-3.2.0.tgz", + "integrity": "sha512-V4Zn/ncyN1QNSqSBxTrMOLpjr+IKdHl2v3KVLoWmDPscP4r9GcCi71gjgvUV1SFSKh92AjAG4peFuBl2/YgCJg==", + "dependencies": { + "@types/mdast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark/node_modules/@types/mdast": { + "version": "3.0.12", + "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.12.tgz", + "integrity": "sha512-DT+iNIRNX884cx0/Q1ja7NyUPpZuv0KPyL5rGNxm1WC1OtHstl7n4Jb7nk+xacNShQMbczJjt8uFzznpp6kYBg==", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/resolve": { + "version": "1.22.4", + "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.4.tgz", + "integrity": "sha512-PXNdCiPqDqeUou+w1C2eTQbNfxKSuMxqTCuvlmmMsk1NWHL5fRrhY6Pl0qEYYc6+QqGClco1Qj8XnjPego4wfg==", + "dev": true, + "dependencies": { + "is-core-module": "^2.13.0", + "path-parse": "^1.0.7", + "supports-preserve-symlinks-flag": "^1.0.0" + }, + "bin": { + "resolve": "bin/resolve" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/resolve-from": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz", + "integrity": "sha512-pb/MYmXstAkysRFx8piNI1tGFNQIFA3vkE3Gq4EuA1dF6gHp/+vgZqsCGJapvy8N3Q+4o7FwvquPJcnZ7RYy4g==", + "dev": true, + "engines": { + "node": ">=4" + } + }, + "node_modules/restore-cursor": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/restore-cursor/-/restore-cursor-3.1.0.tgz", + "integrity": "sha512-l+sSefzHpj5qimhFSE5a8nufZYAM3sBSVMAPtYkmC+4EH2anSGaEMXSD0izRQbu9nfyQ9y5JrVmp7E8oZrUjvA==", + "dependencies": { + "onetime": "^5.1.0", + "signal-exit": "^3.0.2" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/reusify": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz", + "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==", + "dev": true, + "engines": { + "iojs": ">=1.0.0", + "node": ">=0.10.0" + } + }, + "node_modules/rimraf": { + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/rimraf/-/rimraf-3.0.2.tgz", + "integrity": "sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==", + "dev": true, + "dependencies": { + "glob": "^7.1.3" + }, + "bin": { + "rimraf": "bin.js" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/run-async": { + "version": "2.4.1", + "resolved": "https://registry.npmjs.org/run-async/-/run-async-2.4.1.tgz", + "integrity": "sha512-tvVnVv01b8c1RrA6Ep7JkStj85Guv/YrMcwqYQnwjsAS2cTmmPGBBjAjpCW7RrSodNSoE2/qg9O4bceNvUuDgQ==", + "engines": { + "node": ">=0.12.0" + } + }, + "node_modules/run-parallel": { + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz", + "integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "dependencies": { + "queue-microtask": "^1.2.2" + } + }, + "node_modules/rxjs": { + "version": "7.8.1", + "resolved": "https://registry.npmjs.org/rxjs/-/rxjs-7.8.1.tgz", + "integrity": "sha512-AA3TVj+0A2iuIoQkWEK/tqFjBq2j+6PO6Y0zJcvzLAFhEFIO3HL0vls9hWLncZbAAbK0mar7oZ4V079I/qPMxg==", + "dependencies": { + "tslib": "^2.1.0" + } + }, + "node_modules/sade": { + "version": "1.8.1", + "resolved": "https://registry.npmjs.org/sade/-/sade-1.8.1.tgz", + "integrity": "sha512-xal3CZX1Xlo/k4ApwCFrHVACi9fBqJ7V+mwhBsuf/1IOKbBy098Fex+Wa/5QMubw09pSZ/u8EY8PWgevJsXp1A==", + "dependencies": { + "mri": "^1.1.0" + }, + "engines": { + "node": ">=6" + } + }, + "node_modules/safe-array-concat": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/safe-array-concat/-/safe-array-concat-1.0.0.tgz", + "integrity": "sha512-9dVEFruWIsnie89yym+xWTAYASdpw3CJV7Li/6zBewGf9z2i1j31rP6jnY0pHEO4QZh6N0K11bFjWmdR8UGdPQ==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "get-intrinsic": "^1.2.0", + "has-symbols": "^1.0.3", + "isarray": "^2.0.5" + }, + "engines": { + "node": ">=0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/safe-buffer": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", + "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] + }, + "node_modules/safe-regex-test": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/safe-regex-test/-/safe-regex-test-1.0.0.tgz", + "integrity": "sha512-JBUUzyOgEwXQY1NuPtvcj/qcBDbDmEvWufhlnXZIm75DEHp+afM1r1ujJpJsV/gSM4t59tpDyPi1sd6ZaPFfsA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "get-intrinsic": "^1.1.3", + "is-regex": "^1.1.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/safer-buffer": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", + "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==" + }, + "node_modules/semver": { + "version": "6.3.1", + "resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz", + "integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==", + "dev": true, + "bin": { + "semver": "bin/semver.js" + } + }, + "node_modules/shebang-command": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", + "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==", + "dependencies": { + "shebang-regex": "^3.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/shebang-regex": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz", + "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==", + "engines": { + "node": ">=8" + } + }, + "node_modules/side-channel": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.0.4.tgz", + "integrity": "sha512-q5XPytqFEIKHkGdiMIrY10mvLRvnQh42/+GoBlFW3b2LXLE2xxJpZFdm94we0BaoV3RwJyGqg5wS7epxTv0Zvw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.0", + "get-intrinsic": "^1.0.2", + "object-inspect": "^1.9.0" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/signal-exit": { + "version": "3.0.7", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.7.tgz", + "integrity": "sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==" + }, + "node_modules/space-separated-tokens": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/space-separated-tokens/-/space-separated-tokens-2.0.2.tgz", + "integrity": "sha512-PEGlAwrG8yXGXRjW32fGbg66JAlOAwbObuqVoJpv/mRgoWDQfgH1wDPvtzWyUSNAXBGSk8h755YDbbcEy3SH2Q==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/string_decoder": { + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.3.0.tgz", + "integrity": "sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==", + "dependencies": { + "safe-buffer": "~5.2.0" + } + }, + "node_modules/string-width": { + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dependencies": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/string-width-cjs": { + "name": "string-width", + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dependencies": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/string.prototype.trim": { + "version": "1.2.7", + "resolved": "https://registry.npmjs.org/string.prototype.trim/-/string.prototype.trim-1.2.7.tgz", + "integrity": "sha512-p6TmeT1T3411M8Cgg9wBTMRtY2q9+PNy9EV1i2lIXUN/btt763oIfxwN3RR8VU6wHX8j/1CFy0L+YuThm6bgOg==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/string.prototype.trimend": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/string.prototype.trimend/-/string.prototype.trimend-1.0.6.tgz", + "integrity": "sha512-JySq+4mrPf9EsDBEDYMOb/lM7XQLulwg5R/m1r0PXEFqrV0qHvl58sdTilSXtKOflCsK2E8jxf+GKC0T07RWwQ==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/string.prototype.trimstart": { + "version": "1.0.6", + "resolved": "https://registry.npmjs.org/string.prototype.trimstart/-/string.prototype.trimstart-1.0.6.tgz", + "integrity": "sha512-omqjMDaY92pbn5HOX7f9IccLA+U1tA9GvtU4JrodiXFfYB7jPzzHpRzpglLAjtUV6bB557zwClJezTqnAiYnQA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "define-properties": "^1.1.4", + "es-abstract": "^1.20.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/stringify-entities": { + "version": "4.0.3", + "resolved": "https://registry.npmjs.org/stringify-entities/-/stringify-entities-4.0.3.tgz", + "integrity": "sha512-BP9nNHMhhfcMbiuQKCqMjhDP5yBCAxsPu4pHFFzJ6Alo9dZgY4VLDPutXqIjpRiMoKdp7Av85Gr73Q5uH9k7+g==", + "dependencies": { + "character-entities-html4": "^2.0.0", + "character-entities-legacy": "^3.0.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/strip-ansi-cjs": { + "name": "strip-ansi", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/strip-bom": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz", + "integrity": "sha512-vavAMRXOgBVNF6nyEEmL3DBK19iRpDcoIwW+swQ+CbGiu7lju6t+JklA1MHweoWtadgt4ISVUsXLyDq34ddcwA==", + "dev": true, + "engines": { + "node": ">=4" + } + }, + "node_modules/strip-json-comments": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz", + "integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==", + "dev": true, + "engines": { + "node": ">=8" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/supports-color": { + "version": "7.2.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz", + "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==", + "dependencies": { + "has-flag": "^4.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/supports-preserve-symlinks-flag": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/supports-preserve-symlinks-flag/-/supports-preserve-symlinks-flag-1.0.0.tgz", + "integrity": "sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==", + "dev": true, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/text-table": { + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz", + "integrity": "sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==", + "dev": true + }, + "node_modules/through": { + "version": "2.3.8", + "resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz", + "integrity": "sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==" + }, + "node_modules/tmp": { + "version": "0.0.33", + "resolved": "https://registry.npmjs.org/tmp/-/tmp-0.0.33.tgz", + "integrity": "sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw==", + "dependencies": { + "os-tmpdir": "~1.0.2" + }, + "engines": { + "node": ">=0.6.0" + } + }, + "node_modules/to-regex-range": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", + "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", + "dependencies": { + "is-number": "^7.0.0" + }, + "engines": { + "node": ">=8.0" + } + }, + "node_modules/to-vfile": { + "version": "7.2.4", + "resolved": "https://registry.npmjs.org/to-vfile/-/to-vfile-7.2.4.tgz", + "integrity": "sha512-2eQ+rJ2qGbyw3senPI0qjuM7aut8IYXK6AEoOWb+fJx/mQYzviTckm1wDjq91QYHAPBTYzmdJXxMFA6Mk14mdw==", + "dependencies": { + "is-buffer": "^2.0.0", + "vfile": "^5.1.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/to-vfile/node_modules/is-buffer": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", + "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "engines": { + "node": ">=4" + } + }, + "node_modules/trim-lines": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/trim-lines/-/trim-lines-3.0.1.tgz", + "integrity": "sha512-kRj8B+YHZCc9kQYdWfJB2/oUl9rA99qbowYYBtr4ui4mZyAQ2JpvVBd/6U2YloATfqBhBTSMhTpgBHtU0Mf3Rg==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/trough": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/trough/-/trough-2.1.0.tgz", + "integrity": "sha512-AqTiAOLcj85xS7vQ8QkAV41hPDIJ71XJB4RCUrzo/1GM2CQwhkJGaf9Hgr7BOugMRpgGUrqRg/DrBDl4H40+8g==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/tsconfig-paths": { + "version": "3.14.2", + "resolved": "https://registry.npmjs.org/tsconfig-paths/-/tsconfig-paths-3.14.2.tgz", + "integrity": "sha512-o/9iXgCYc5L/JxCHPe3Hvh8Q/2xm5Z+p18PESBU6Ff33695QnCHBEjcytY2q19ua7Mbl/DavtBOLq+oG0RCL+g==", + "dev": true, + "dependencies": { + "@types/json5": "^0.0.29", + "json5": "^1.0.2", + "minimist": "^1.2.6", + "strip-bom": "^3.0.0" + } + }, + "node_modules/tslib": { + "version": "2.6.1", + "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.6.1.tgz", + "integrity": "sha512-t0hLfiEKfMUoqhG+U1oid7Pva4bbDPHYfJNiB7BiIjRkj1pyC++4N3huJfqY6aRH6VTB0rvtzQwjM4K6qpfOig==" + }, + "node_modules/type-check": { + "version": "0.4.0", + "resolved": "https://registry.npmjs.org/type-check/-/type-check-0.4.0.tgz", + "integrity": "sha512-XleUoc9uwGXqjWwXaUTZAmzMcFZ5858QA2vvx1Ur5xIcixXIP+8LnFDgRplU30us6teqdlskFfu+ae4K79Ooew==", + "dev": true, + "dependencies": { + "prelude-ls": "^1.2.1" + }, + "engines": { + "node": ">= 0.8.0" + } + }, + "node_modules/type-fest": { + "version": "0.20.2", + "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.20.2.tgz", + "integrity": "sha512-Ne+eE4r0/iWnpAxD852z3A+N0Bt5RN//NjJwRd2VFHEmrywxf5vsZlh4R6lixl6B+wz/8d+maTSAkN1FIkI3LQ==", + "dev": true, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/typed-array-buffer": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/typed-array-buffer/-/typed-array-buffer-1.0.0.tgz", + "integrity": "sha512-Y8KTSIglk9OZEr8zywiIHG/kmQ7KWyjseXs1CbSo8vC42w7hg2HgYTxSWwP0+is7bWDc1H+Fo026CpHFwm8tkw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "get-intrinsic": "^1.2.1", + "is-typed-array": "^1.1.10" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/typed-array-byte-length": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/typed-array-byte-length/-/typed-array-byte-length-1.0.0.tgz", + "integrity": "sha512-Or/+kvLxNpeQ9DtSydonMxCx+9ZXOswtwJn17SNLvhptaXYDJvkFFP5zbfU/uLmvnBJlI4yrnXRxpdWH/M5tNA==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "for-each": "^0.3.3", + "has-proto": "^1.0.1", + "is-typed-array": "^1.1.10" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/typed-array-byte-offset": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/typed-array-byte-offset/-/typed-array-byte-offset-1.0.0.tgz", + "integrity": "sha512-RD97prjEt9EL8YgAgpOkf3O4IF9lhJFr9g0htQkm0rchFp/Vx7LW5Q8fSXXub7BXAODyUQohRMyOc3faCPd0hg==", + "dev": true, + "dependencies": { + "available-typed-arrays": "^1.0.5", + "call-bind": "^1.0.2", + "for-each": "^0.3.3", + "has-proto": "^1.0.1", + "is-typed-array": "^1.1.10" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/typed-array-length": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/typed-array-length/-/typed-array-length-1.0.4.tgz", + "integrity": "sha512-KjZypGq+I/H7HI5HlOoGHkWUUGq+Q0TPhQurLbyrVrvnKTBgzLhIJ7j6J/XTQOi0d1RjyZ0wdas8bKs2p0x3Ng==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "for-each": "^0.3.3", + "is-typed-array": "^1.1.9" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/typedarray": { + "version": "0.0.6", + "resolved": "https://registry.npmjs.org/typedarray/-/typedarray-0.0.6.tgz", + "integrity": "sha512-/aCDEGatGvZ2BIk+HmLf4ifCJFwvKFNb9/JeZPMulfgFracn9QFcAf5GO8B/mweUjSoblS5In0cWhqpfs/5PQA==" + }, + "node_modules/unbox-primitive": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/unbox-primitive/-/unbox-primitive-1.0.2.tgz", + "integrity": "sha512-61pPlCD9h51VoreyJ0BReideM3MDKMKnh6+V9L08331ipq6Q8OFXZYiqP6n/tbHx4s5I9uRhcye6BrbkizkBDw==", + "dev": true, + "dependencies": { + "call-bind": "^1.0.2", + "has-bigints": "^1.0.2", + "has-symbols": "^1.0.3", + "which-boxed-primitive": "^1.0.2" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/unified": { + "version": "10.1.2", + "resolved": "https://registry.npmjs.org/unified/-/unified-10.1.2.tgz", + "integrity": "sha512-pUSWAi/RAnVy1Pif2kAoeWNBa3JVrx0MId2LASj8G+7AiHWoKZNTomq6LG326T68U7/e263X6fTdcXIy7XnF7Q==", + "dependencies": { + "@types/unist": "^2.0.0", + "bail": "^2.0.0", + "extend": "^3.0.0", + "is-buffer": "^2.0.0", + "is-plain-obj": "^4.0.0", + "trough": "^2.0.0", + "vfile": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-engine": { + "version": "10.1.0", + "resolved": "https://registry.npmjs.org/unified-engine/-/unified-engine-10.1.0.tgz", + "integrity": "sha512-5+JDIs4hqKfHnJcVCxTid1yBoI/++FfF/1PFdSMpaftZZZY+qg2JFruRbf7PaIwa9KgLotXQV3gSjtY0IdcFGQ==", + "dependencies": { + "@types/concat-stream": "^2.0.0", + "@types/debug": "^4.0.0", + "@types/is-empty": "^1.0.0", + "@types/node": "^18.0.0", + "@types/unist": "^2.0.0", + "concat-stream": "^2.0.0", + "debug": "^4.0.0", + "fault": "^2.0.0", + "glob": "^8.0.0", + "ignore": "^5.0.0", + "is-buffer": "^2.0.0", + "is-empty": "^1.0.0", + "is-plain-obj": "^4.0.0", + "load-plugin": "^5.0.0", + "parse-json": "^6.0.0", + "to-vfile": "^7.0.0", + "trough": "^2.0.0", + "unist-util-inspect": "^7.0.0", + "vfile-message": "^3.0.0", + "vfile-reporter": "^7.0.0", + "vfile-statistics": "^2.0.0", + "yaml": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-engine/node_modules/ansi-regex": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz", + "integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-regex?sponsor=1" + } + }, + "node_modules/unified-engine/node_modules/brace-expansion": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", + "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dependencies": { + "balanced-match": "^1.0.0" + } + }, + "node_modules/unified-engine/node_modules/emoji-regex": { + "version": "9.2.2", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", + "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==" + }, + "node_modules/unified-engine/node_modules/glob": { + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/glob/-/glob-8.1.0.tgz", + "integrity": "sha512-r8hpEjiQEYlF2QU0df3dS+nxxSIreXQS1qRhMJM0Q5NDdR386C7jb7Hwwod8Fgiuex+k0GFjgft18yvxm5XoCQ==", + "dependencies": { + "fs.realpath": "^1.0.0", + "inflight": "^1.0.4", + "inherits": "2", + "minimatch": "^5.0.1", + "once": "^1.3.0" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, + "node_modules/unified-engine/node_modules/is-buffer": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", + "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "engines": { + "node": ">=4" + } + }, + "node_modules/unified-engine/node_modules/minimatch": { + "version": "5.1.6", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.6.tgz", + "integrity": "sha512-lKwV/1brpG6mBUFHtb7NUmtABCb2WZZmm2wNiOA5hAb8VdCS4B3dtMWyvcoViccwAW/COERjXLt0zP1zXUN26g==", + "dependencies": { + "brace-expansion": "^2.0.1" + }, + "engines": { + "node": ">=10" + } + }, + "node_modules/unified-engine/node_modules/string-width": { + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", + "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", + "dependencies": { + "eastasianwidth": "^0.2.0", + "emoji-regex": "^9.2.2", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/unified-engine/node_modules/strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dependencies": { + "ansi-regex": "^6.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" + } + }, + "node_modules/unified-engine/node_modules/supports-color": { + "version": "9.4.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-9.4.0.tgz", + "integrity": "sha512-VL+lNrEoIXww1coLPOmiEmK/0sGigko5COxI09KzHc2VJXJsQ37UaQ+8quuxjDeA7+KnLGTWRyOXSLLR2Wb4jw==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/supports-color?sponsor=1" + } + }, + "node_modules/unified-engine/node_modules/vfile-reporter": { + "version": "7.0.5", + "resolved": "https://registry.npmjs.org/vfile-reporter/-/vfile-reporter-7.0.5.tgz", + "integrity": "sha512-NdWWXkv6gcd7AZMvDomlQbK3MqFWL1RlGzMn++/O2TI+68+nqxCPTvLugdOtfSzXmjh+xUyhp07HhlrbJjT+mw==", + "dependencies": { + "@types/supports-color": "^8.0.0", + "string-width": "^5.0.0", + "supports-color": "^9.0.0", + "unist-util-stringify-position": "^3.0.0", + "vfile": "^5.0.0", + "vfile-message": "^3.0.0", + "vfile-sort": "^3.0.0", + "vfile-statistics": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-engine/node_modules/vfile-sort": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/vfile-sort/-/vfile-sort-3.0.1.tgz", + "integrity": "sha512-1os1733XY6y0D5x0ugqSeaVJm9lYgj0j5qdcZQFyxlZOSy1jYarL77lLyb5gK4Wqr1d5OxmuyflSO3zKyFnTFw==", + "dependencies": { + "vfile": "^5.0.0", + "vfile-message": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-lint-rule": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/unified-lint-rule/-/unified-lint-rule-2.1.2.tgz", + "integrity": "sha512-JWudPtRN7TLFHVLEVZ+Rm8FUb6kCAtHxEXFgBGDxRSdNMnGyTU5zyYvduHSF/liExlFB3vdFvsAHnNVE/UjAwA==", + "dependencies": { + "@types/unist": "^2.0.0", + "trough": "^2.0.0", + "unified": "^10.0.0", + "vfile": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-message-control": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/unified-message-control/-/unified-message-control-4.0.0.tgz", + "integrity": "sha512-1b92N+VkPHftOsvXNOtkJm4wHlr+UDmTBF2dUzepn40oy9NxanJ9xS1RwUBTjXJwqr2K0kMbEyv1Krdsho7+Iw==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0", + "unist-util-visit": "^3.0.0", + "vfile": "^5.0.0", + "vfile-location": "^4.0.0", + "vfile-message": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-message-control/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-message-control/node_modules/unist-util-visit": { + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-3.1.0.tgz", + "integrity": "sha512-Szoh+R/Ll68QWAyQyZZpQzZQm2UPbxibDvaY8Xc9SUtYgPsDzx5AWSk++UUt2hJuow8mvwR+rG+LQLw+KsuAKA==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0", + "unist-util-visit-parents": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-message-control/node_modules/unist-util-visit-parents": { + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-4.1.1.tgz", + "integrity": "sha512-1xAFJXAKpnnJl8G7K5KgU7FY55y3GcLIXqkzUj5QF/QVP7biUm0K0O2oqVkYsdjzJKifYeWn9+o6piAK2hGSHw==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified/node_modules/is-buffer": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", + "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "engines": { + "node": ">=4" + } + }, + "node_modules/unist-builder": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/unist-builder/-/unist-builder-4.0.0.tgz", + "integrity": "sha512-wmRFnH+BLpZnTKpc5L7O67Kac89s9HMrtELpnNaE6TAobq5DTZZs5YaTQfAZBA9bFPECx2uVAPO31c+GVug8mg==", + "dependencies": { + "@types/unist": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-builder/node_modules/@types/unist": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.0.tgz", + "integrity": "sha512-MFETx3tbTjE7Uk6vvnWINA/1iJ7LuMdO4fcq8UfF0pRbj01aGLduVvQcRyswuACJdpnHgg8E3rQLhaRdNEJS0w==" + }, + "node_modules/unist-util-find-after": { + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/unist-util-find-after/-/unist-util-find-after-4.0.1.tgz", + "integrity": "sha512-QO/PuPMm2ERxC6vFXEPtmAutOopy5PknD+Oq64gGwxKtk4xwo9Z97t9Av1obPmGU0IyTa6EKYUfTrK2QJS3Ozw==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-find-after/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-find-between-all": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/unist-util-find-between-all/-/unist-util-find-between-all-1.0.4.tgz", + "integrity": "sha512-ajy0Jyx7SIPfbSKNRdFRtUx0Ei+z0X9xjcX1rYW2YknU2NzG71JWZoqmRrga+/mCkbfYA7pphjlFfHAMcngaUQ==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-find-between-all/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-generated": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/unist-util-generated/-/unist-util-generated-2.0.1.tgz", + "integrity": "sha512-qF72kLmPxAw0oN2fwpWIqbXAVyEqUzDHMsbtPvOudIlUzXYFIeQIuxXQCRCFh22B7cixvU0MG7m3MW8FTq/S+A==", + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-inspect": { + "version": "7.0.2", + "resolved": "https://registry.npmjs.org/unist-util-inspect/-/unist-util-inspect-7.0.2.tgz", + "integrity": "sha512-Op0XnmHUl6C2zo/yJCwhXQSm/SmW22eDZdWP2qdf4WpGrgO1ZxFodq+5zFyeRGasFjJotAnLgfuD1jkcKqiH1Q==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-is": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-6.0.0.tgz", + "integrity": "sha512-2qCTHimwdxLfz+YzdGfkqNlH0tLi9xjTnHddPmJwtIG9MGsdbutfTc4P+haPD7l7Cjxf/WZj+we5qfVPvvxfYw==", + "dependencies": { + "@types/unist": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-is/node_modules/@types/unist": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.0.tgz", + "integrity": "sha512-MFETx3tbTjE7Uk6vvnWINA/1iJ7LuMdO4fcq8UfF0pRbj01aGLduVvQcRyswuACJdpnHgg8E3rQLhaRdNEJS0w==" + }, + "node_modules/unist-util-map": { + "version": "3.1.3", + "resolved": "https://registry.npmjs.org/unist-util-map/-/unist-util-map-3.1.3.tgz", + "integrity": "sha512-4/mDauoxqZ6geK97lJ6n2kDk6JK88Vh+hWMSJqyaaP/7eqN1dDhjcjnNxKNm3YU6Sw7PVJtcFMUbnmHvYzb6Vg==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-position": { + "version": "4.0.4", + "resolved": "https://registry.npmjs.org/unist-util-position/-/unist-util-position-4.0.4.tgz", + "integrity": "sha512-kUBE91efOWfIVBo8xzh/uZQ7p9ffYRtUbMRZBNFYwf0RK8koUMx6dGUfwylLOKmaT2cs4wSW96QoYUSXAyEtpg==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-stringify-position": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-3.0.3.tgz", + "integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-visit": { + "version": "4.1.2", + "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-4.1.2.tgz", + "integrity": "sha512-MSd8OUGISqHdVvfY9TPhyK2VdUrPgxkUtWSuMHF6XAAFuL4LokseigBnZtPnJMu+FbynTkFNnFlyjxpVKujMRg==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0", + "unist-util-visit-parents": "^5.1.1" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-visit-parents": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-6.0.1.tgz", + "integrity": "sha512-L/PqWzfTP9lzzEa6CKs0k2nARxTdZduw3zyh8d2NVBnsyvHjSX4TWse388YrrQKbvI8w20fGjGlhgT96WwKykw==", + "dependencies": { + "@types/unist": "^3.0.0", + "unist-util-is": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-visit-parents/node_modules/@types/unist": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.0.tgz", + "integrity": "sha512-MFETx3tbTjE7Uk6vvnWINA/1iJ7LuMdO4fcq8UfF0pRbj01aGLduVvQcRyswuACJdpnHgg8E3rQLhaRdNEJS0w==" + }, + "node_modules/unist-util-visit/node_modules/unist-util-is": { + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz", + "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==", + "dependencies": { + "@types/unist": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unist-util-visit/node_modules/unist-util-visit-parents": { + "version": "5.1.3", + "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-5.1.3.tgz", + "integrity": "sha512-x6+y8g7wWMyQhL1iZfhIPhDAs7Xwbn9nRosDXl7qoPTSCy0yNxnKc+hWokFifWQIDGi154rdUqKvbCa4+1kLhg==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-is": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/universalify": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.0.tgz", + "integrity": "sha512-hAZsKq7Yy11Zu1DE0OzWjw7nnLZmJZYTDZZyEFHZdUhV8FkH5MCfoU1XMaxXovpyW5nq5scPqq0ZDP9Zyl04oQ==", + "engines": { + "node": ">= 10.0.0" + } + }, + "node_modules/uri-js": { + "version": "4.4.1", + "resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz", + "integrity": "sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==", + "dev": true, + "dependencies": { + "punycode": "^2.1.0" + } + }, + "node_modules/util-deprecate": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz", + "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==" + }, + "node_modules/uvu": { + "version": "0.5.6", + "resolved": "https://registry.npmjs.org/uvu/-/uvu-0.5.6.tgz", + "integrity": "sha512-+g8ENReyr8YsOc6fv/NVJs2vFdHBnBNdfE49rshrTzDWOlUx4Gq7KOS2GD8eqhy2j+Ejq29+SbKH8yjkAqXqoA==", + "dependencies": { + "dequal": "^2.0.0", + "diff": "^5.0.0", + "kleur": "^4.0.3", + "sade": "^1.7.3" + }, + "bin": { + "uvu": "bin.js" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/vfile": { + "version": "5.3.7", + "resolved": "https://registry.npmjs.org/vfile/-/vfile-5.3.7.tgz", + "integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==", + "dependencies": { + "@types/unist": "^2.0.0", + "is-buffer": "^2.0.0", + "unist-util-stringify-position": "^3.0.0", + "vfile-message": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-location": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/vfile-location/-/vfile-location-4.1.0.tgz", + "integrity": "sha512-YF23YMyASIIJXpktBa4vIGLJ5Gs88UB/XePgqPmTa7cDA+JeO3yclbpheQYCHjVHBn/yePzrXuygIL+xbvRYHw==", + "dependencies": { + "@types/unist": "^2.0.0", + "vfile": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-message": { + "version": "3.1.4", + "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-3.1.4.tgz", + "integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==", + "dependencies": { + "@types/unist": "^2.0.0", + "unist-util-stringify-position": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-reporter": { + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/vfile-reporter/-/vfile-reporter-8.1.0.tgz", + "integrity": "sha512-NfHyHdkCcy0BsXiLA3nId29TY7W7hgpc8nd8Soe3imATx5N4/+mkLYdMR+Y6Zvu6BXMMi0FZsD4FLCm1dN85Pg==", + "dependencies": { + "@types/supports-color": "^8.0.0", + "string-width": "^6.0.0", + "supports-color": "^9.0.0", + "unist-util-stringify-position": "^4.0.0", + "vfile": "^6.0.0", + "vfile-message": "^4.0.0", + "vfile-sort": "^4.0.0", + "vfile-statistics": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-reporter/node_modules/@types/unist": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.0.tgz", + "integrity": "sha512-MFETx3tbTjE7Uk6vvnWINA/1iJ7LuMdO4fcq8UfF0pRbj01aGLduVvQcRyswuACJdpnHgg8E3rQLhaRdNEJS0w==" + }, + "node_modules/vfile-reporter/node_modules/ansi-regex": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz", + "integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-regex?sponsor=1" + } + }, + "node_modules/vfile-reporter/node_modules/emoji-regex": { + "version": "10.2.1", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-10.2.1.tgz", + "integrity": "sha512-97g6QgOk8zlDRdgq1WxwgTMgEWGVAQvB5Fdpgc1MkNy56la5SKP9GsMXKDOdqwn90/41a8yPwIGk1Y6WVbeMQA==" + }, + "node_modules/vfile-reporter/node_modules/string-width": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-6.1.0.tgz", + "integrity": "sha512-k01swCJAgQmuADB0YIc+7TuatfNvTBVOoaUWJjTB9R4VJzR5vNWzf5t42ESVZFPS8xTySF7CAdV4t/aaIm3UnQ==", + "dependencies": { + "eastasianwidth": "^0.2.0", + "emoji-regex": "^10.2.1", + "strip-ansi": "^7.0.1" + }, + "engines": { + "node": ">=16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/vfile-reporter/node_modules/strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dependencies": { + "ansi-regex": "^6.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" + } + }, + "node_modules/vfile-reporter/node_modules/supports-color": { + "version": "9.4.0", + "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-9.4.0.tgz", + "integrity": "sha512-VL+lNrEoIXww1coLPOmiEmK/0sGigko5COxI09KzHc2VJXJsQ37UaQ+8quuxjDeA7+KnLGTWRyOXSLLR2Wb4jw==", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/supports-color?sponsor=1" + } + }, + "node_modules/vfile-reporter/node_modules/unist-util-stringify-position": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-4.0.0.tgz", + "integrity": "sha512-0ASV06AAoKCDkS2+xw5RXJywruurpbC4JZSm7nr7MOt1ojAzvyyaO+UxZf18j8FCF6kmzCZKcAgN/yu2gm2XgQ==", + "dependencies": { + "@types/unist": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-reporter/node_modules/vfile": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/vfile/-/vfile-6.0.1.tgz", + "integrity": "sha512-1bYqc7pt6NIADBJ98UiG0Bn/CHIVOoZ/IyEkqIruLg0mE1BKzkOXY2D6CSqQIcKqgadppE5lrxgWXJmXd7zZJw==", + "dependencies": { + "@types/unist": "^3.0.0", + "unist-util-stringify-position": "^4.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-reporter/node_modules/vfile-message": { + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-4.0.2.tgz", + "integrity": "sha512-jRDZ1IMLttGj41KcZvlrYAaI3CfqpLpfpf+Mfig13viT6NKvRzWZ+lXz0Y5D60w6uJIBAOGq9mSHf0gktF0duw==", + "dependencies": { + "@types/unist": "^3.0.0", + "unist-util-stringify-position": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-reporter/node_modules/vfile-statistics": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/vfile-statistics/-/vfile-statistics-3.0.0.tgz", + "integrity": "sha512-/qlwqwWBWFOmpXujL/20P+Iuydil0rZZNglR+VNm6J0gpLHwuVM5s7g2TfVoswbXjZ4HuIhLMySEyIw5i7/D8w==", + "dependencies": { + "vfile": "^6.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-sort": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/vfile-sort/-/vfile-sort-4.0.0.tgz", + "integrity": "sha512-lffPI1JrbHDTToJwcq0rl6rBmkjQmMuXkAxsZPRS9DXbaJQvc642eCg6EGxcX2i1L+esbuhq+2l9tBll5v8AeQ==", + "dependencies": { + "vfile": "^6.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-sort/node_modules/@types/unist": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.0.tgz", + "integrity": "sha512-MFETx3tbTjE7Uk6vvnWINA/1iJ7LuMdO4fcq8UfF0pRbj01aGLduVvQcRyswuACJdpnHgg8E3rQLhaRdNEJS0w==" + }, + "node_modules/vfile-sort/node_modules/unist-util-stringify-position": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-4.0.0.tgz", + "integrity": "sha512-0ASV06AAoKCDkS2+xw5RXJywruurpbC4JZSm7nr7MOt1ojAzvyyaO+UxZf18j8FCF6kmzCZKcAgN/yu2gm2XgQ==", + "dependencies": { + "@types/unist": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-sort/node_modules/vfile": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/vfile/-/vfile-6.0.1.tgz", + "integrity": "sha512-1bYqc7pt6NIADBJ98UiG0Bn/CHIVOoZ/IyEkqIruLg0mE1BKzkOXY2D6CSqQIcKqgadppE5lrxgWXJmXd7zZJw==", + "dependencies": { + "@types/unist": "^3.0.0", + "unist-util-stringify-position": "^4.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-sort/node_modules/vfile-message": { + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-4.0.2.tgz", + "integrity": "sha512-jRDZ1IMLttGj41KcZvlrYAaI3CfqpLpfpf+Mfig13viT6NKvRzWZ+lXz0Y5D60w6uJIBAOGq9mSHf0gktF0duw==", + "dependencies": { + "@types/unist": "^3.0.0", + "unist-util-stringify-position": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile-statistics": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/vfile-statistics/-/vfile-statistics-2.0.1.tgz", + "integrity": "sha512-W6dkECZmP32EG/l+dp2jCLdYzmnDBIw6jwiLZSER81oR5AHRcVqL+k3Z+pfH1R73le6ayDkJRMk0sutj1bMVeg==", + "dependencies": { + "vfile": "^5.0.0", + "vfile-message": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/vfile/node_modules/is-buffer": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", + "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "engines": { + "node": ">=4" + } + }, + "node_modules/walk-up-path": { + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/walk-up-path/-/walk-up-path-3.0.1.tgz", + "integrity": "sha512-9YlCL/ynK3CTlrSRrDxZvUauLzAswPCrsaCgilqFevUYpeEW0/3ScEjaa3kbW/T0ghhkEr7mv+fpjqn1Y1YuTA==" + }, + "node_modules/wcwidth": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/wcwidth/-/wcwidth-1.0.1.tgz", + "integrity": "sha512-XHPEwS0q6TaxcvG85+8EYkbiCux2XtWG2mkc47Ng2A77BQu9+DqIOJldST4HgPkuea7dvKSj5VgX3P1d4rW8Tg==", + "dependencies": { + "defaults": "^1.0.3" + } + }, + "node_modules/web-namespaces": { + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/web-namespaces/-/web-namespaces-2.0.1.tgz", + "integrity": "sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/which": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", + "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", + "dependencies": { + "isexe": "^2.0.0" + }, + "bin": { + "node-which": "bin/node-which" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/which-boxed-primitive": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/which-boxed-primitive/-/which-boxed-primitive-1.0.2.tgz", + "integrity": "sha512-bwZdv0AKLpplFY2KZRX6TvyuN7ojjr7lwkg6ml0roIy9YeuSr7JS372qlNW18UQYzgYK9ziGcerWqZOmEn9VNg==", + "dev": true, + "dependencies": { + "is-bigint": "^1.0.1", + "is-boolean-object": "^1.1.0", + "is-number-object": "^1.0.4", + "is-string": "^1.0.5", + "is-symbol": "^1.0.3" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/which-typed-array": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/which-typed-array/-/which-typed-array-1.1.11.tgz", + "integrity": "sha512-qe9UWWpkeG5yzZ0tNYxDmd7vo58HDBc39mZ0xWWpolAGADdFOzkfamWLDxkOWcvHQKVmdTyQdLD4NOfjLWTKew==", + "dev": true, + "dependencies": { + "available-typed-arrays": "^1.0.5", + "call-bind": "^1.0.2", + "for-each": "^0.3.3", + "gopd": "^1.0.1", + "has-tostringtag": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/wrap-ansi": { + "version": "6.2.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-6.2.0.tgz", + "integrity": "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==", + "dependencies": { + "ansi-styles": "^4.0.0", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi-cjs": { + "name": "wrap-ansi", + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz", + "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==", + "dependencies": { + "ansi-styles": "^4.0.0", + "string-width": "^4.1.0", + "strip-ansi": "^6.0.0" + }, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/chalk/wrap-ansi?sponsor=1" + } + }, + "node_modules/wrappy": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", + "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==" + }, + "node_modules/yallist": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz", + "integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==" + }, + "node_modules/yaml": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.3.1.tgz", + "integrity": "sha512-2eHWfjaoXgTBC2jNM1LRef62VQa0umtvRiDSk6HSzW7RvS5YtkabJrwYLLEKWBc8a5U2PTSCs+dJjUTJdlHsWQ==", + "engines": { + "node": ">= 14" + } + }, + "node_modules/yocto-queue": { + "version": "0.1.0", + "resolved": "https://registry.npmjs.org/yocto-queue/-/yocto-queue-0.1.0.tgz", + "integrity": "sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==", + "dev": true, + "engines": { + "node": ">=10" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, + "node_modules/zwitch": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/zwitch/-/zwitch-2.0.4.tgz", + "integrity": "sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A==", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + } + } +} diff --git a/package.json b/package.json new file mode 100644 index 00000000..3e806283 --- /dev/null +++ b/package.json @@ -0,0 +1,36 @@ +{ + "name": "@json-schema-org/json-schema-spec", + "version": "1.0.0", + "description": "The JSON Schema Specification", + "type": "module", + "main": "index.js", + "scripts": { + "lint": "eslint build/", + "build": "npm run build-core && npm run build-validation", + "build-core": "node build/build.js < jsonschema-core.md > jsonschema-core.html", + "build-validation": "node build/build.js < jsonschema-validation.md > jsonschema-validation.html" + }, + "license": "MIT", + "dependencies": { + "mdast-builder": "^1.1.1", + "mdast-util-find-and-replace": "^3.0.0", + "mdast-util-to-string": "^4.0.0", + "rehype-stringify": "^9.0.3", + "remark": "^14.0.3", + "remark-flexible-containers": "^1.0.6", + "remark-gfm": "^3.0.1", + "remark-heading-id": "^1.0.0", + "remark-preset-lint-markdown-style-guide": "^5.1.3", + "remark-rehype": "^10.1.0", + "remark-torchlight": "^0.0.5", + "remark-validate-links": "^12.1.1", + "unist-builder": "^4.0.0", + "vfile-reporter": "^8.0.0" + }, + "devDependencies": { + "dotenv": "^16.3.1", + "eslint": "^8.47.0", + "eslint-import-resolver-node": "^0.3.9", + "eslint-plugin-import": "^2.28.0" + } +}