@wp-typia/block-runtime

Generated-project runtime and metadata sync helpers for wp-typia.

This is the supported generated-project package boundary for:

• manifest-driven defaults
• editor model generation
• manifest-driven inspector helpers
• validation-aware attribute updates
• TypeScript-to-metadata sync
• typed block nesting contracts for parent, ancestor, and allowedBlocks
• generated InnerBlocks template constants validated against nesting contracts
• serialized pattern content validation against typed block nesting contracts
• manifest-first REST/OpenAPI/client codegen

It does not include:

• scaffold or CLI internals
• migration tooling

Typical usage:

import { createEditorModel } from '@wp-typia/block-runtime/editor';
import {
  InspectorFromManifest,
  usePersistentBlockIdentity,
  useEditorFields,
} from '@wp-typia/block-runtime/inspector';
import { collectPersistentBlockIdentityRepairs } from '@wp-typia/block-runtime/identifiers';
import { assertResponseMatchesSchema } from '@wp-typia/block-runtime/schema-test';
import { createNestedAttributeUpdater } from '@wp-typia/block-runtime/validation';
import {
  defineBlockNesting,
  runSyncBlockMetadata,
} from '@wp-typia/block-runtime/metadata-core';
import type { tags } from '@wp-typia/block-runtime/typia-tags';

wp-typia remains the CLI package.

Import tags from @wp-typia/block-runtime/typia-tags when REST settings contracts need wp-typia-only metadata such as tags.Secret<"hasApiKey"> and tags.PreserveOnEmpty<true> for write-only credentials.

@wp-typia/project-tools is the canonical programmatic project orchestration package, while newly generated projects should prefer @wp-typia/block-runtime/* and @wp-typia/block-runtime/metadata-core.

Public subpaths such as @wp-typia/block-runtime/inspector, @wp-typia/block-runtime/metadata-core, and @wp-typia/block-runtime/schema-core stay stable even as their implementations are split into smaller focused modules internally. @wp-typia/block-runtime/schema-test adds test-only helpers for asserting smoke/integration response payloads against generated *.schema.json artifacts. Consumers should keep importing the documented facade subpaths rather than reaching into those helper files directly.

Advanced helper entrypoints such as metadata-analysis, metadata-model, metadata-parser, metadata-php-render, metadata-projection, identifiers, and json-utils are also published and documented, but they are secondary to the main generated-project runtime roots. The canonical hosted reference now splits these into Core API, Advanced Helpers, and Internal APIs sections under https://imjlk.github.io/wp-typia/.

For structured document blocks that need stable logical ids separate from the editor clientId, use:

• collectPersistentBlockIdentityRepairs(...) from @wp-typia/block-runtime/identifiers when you already have a plain block tree and want deterministic duplicate-safe repairs without React.
• usePersistentBlockIdentity(...) from @wp-typia/block-runtime/inspector when you are inside a block edit component and want the same repair logic wired to setAttributes(...).