# Interface: InkHashtagCommandInfo (/jsdoc/pixi-vn-ink/vite/interfaces/InkHashtagCommandInfo)



Defined in: [src/parser/types.ts:63](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L63)

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

## See [#see]

[https://pixi-vn.com/ink#vite-plugin](https://pixi-vn.com/ink#vite-plugin)

## Properties [#properties]

### deprecated? [#deprecated]

\> `optional` **deprecated?**: `boolean`

Defined in: [src/parser/types.ts:105](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L105)

Whether this handler is deprecated. Matches HashtagHandlerOptions.deprecated.

***

### description? [#description]

\> `optional` **description?**: `string`

Defined in: [src/parser/types.ts:71](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L71)

Human-readable description of what the handler does.

***

### keySchemas? [#keyschemas]

\> `optional` &#x2A;*keySchemas?**: `Record`\<`string` | `number`, `object`>

Defined in: [src/parser/types.ts:168](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L168)

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](#validation)).

#### See [#see-1]

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

#### Examples [#examples]

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

```ts
{
  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:

```ts
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:

```ts
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]

\> **name**: `string`

Defined in: [src/parser/types.ts:67](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L67)

Unique name that identifies the handler.

***

### validation [#validation]

\> **validation**: `InkValidationInfo`

Defined in: [src/parser/types.ts:101](https://github.com/DRincs-Productions/pixi-vn-ink/blob/8d45a4e5f29997844c9784f1a713b33e5400b7d0/src/parser/types.ts#L101)

Serializable form of the validation rule.

#### Examples [#examples-1]

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

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

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

```ts
{
  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:

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