Interface: InkHashtagCommandInfo

Defined in: src/parser/types.ts:63

Serializable representation of a registered HashtagCommands handler, as exposed by the pixi-vn-ink Vite dev-server API.

See

https://pixi-vn.com/ink#vite-plugin

Properties

deprecated?

> optional deprecated?: boolean

Defined in: src/parser/types.ts:105

Whether this handler is deprecated. Matches HashtagHandlerOptions.deprecated.

description?

> optional description?: string

Defined in: src/parser/types.ts:71

Human-readable description of what the handler does.

keySchemas?

> optional keySchemas?: Record<string | number, object>

Defined in: src/parser/types.ts:168

JSON Schemas (usable with Ajv), keyed by the token that introduces an order-independent <key> <value> [<value2> ...] section of the command's tokens. Matches HashtagHandlerOptions.keySchemas — already plain JSON Schema objects, so no extra serialization step is needed (unlike validation).

See

InkCompiler.validateKeyedJsonSchemas for how a token list is split into sections and validated against these schemas.

Examples

For the command # wait hours 3 days tomorrow (tokens ["wait", "hours", "3", "days", "tomorrow"]):

{
  name: "wait-with-options",
  validation: { type: "regexp", source: "^wait\\b", flags: "" },
  keySchemas: {
    wait: {
      type: "object",
      properties: { hours: { type: "number" }, days: { type: "string" } },
      additionalProperties: false,
    },
  },
}

InkCompiler.getHashtagKeySchemaIssues matches "wait" (the right-most, and only, occurrence) and validates { hours: 3, days: "tomorrow" } against its schema.

For # show imagecontainer sly props xAlign 0.2 yAlign 1 movein direction right ease anticipate, with two independent sections:

keySchemas: {
  props: { type: "object", properties: { xAlign: { type: "number" }, yAlign: { type: "number" } } },
  movein: { type: "object", properties: { direction: { type: "string" }, ease: { type: "string" } } },
}

A key can also be a (positive integer) number — or a string made only of digits, since object keys are always strings at runtime — instead of a literal token. Numeric keys are resolved by position rather than by token identity, and are checked only after every string key has already claimed its section (right to left, exactly as above); counting starts at 0 for the command's own leading literal (e.g. "show"). Numeric keys are then processed largest to smallest: key N claims tokens[N .. end) as its section (end being the left edge of the previously-claimed section), is validated against its schema, and the token immediately before it (tokens[N - 1], e.g. a dynamic alias that can't be matched by literal value) is dropped along with it — so the next, smaller numeric key resumes scanning to its left.

For # show spine flowerTop x 220 y 20 with dissolve duration 2 (tokens ["show","spine","flowerTop","x","220","y","20","with","dissolve","duration","2"]) with:

keySchemas: {
  with: {},
  dissolve: { type: "object", properties: { duration: { type: "number" } } },
  3: { type: "object", properties: { x: { type: "number" }, y: { type: "number" } } },
}

String keys are resolved first: "dissolve" (right-most) claims { duration: 2 }, then "with" claims an empty section — leaving ["show","spine","flowerTop","x","220","y","20"] ("show" is position 0) for the numeric pass. Key 3 claims tokens[3..7) → { x: 220, y: 20 }, and also drops "flowerTop" (position 2, the element's dynamic alias) — nothing is left to check further left.

name

> name: string

Defined in: src/parser/types.ts:67

Unique name that identifies the handler.

validation

> validation: InkValidationInfo

Defined in: src/parser/types.ts:101

Serializable form of the validation rule.

Examples

A RegExp validation (e.g. /^jump\b/) serializes to:

{ type: "regexp", source: "^jump\\b", flags: "" }

A Zod validation (e.g. z.tuple([z.literal("jump"), z.string()])) serializes to its JSON Schema form:

{
  type: "zod",
  schema: {
    type: "array",
    prefixItems: [{ type: "string", const: "jump" }, { type: "string" }],
    minItems: 2,
    maxItems: 2,
  },
}

A string-literal validation (e.g. TextReplaces' "all" / "characterId" modes) serializes to:

{ type: "literal", value: "all" }