Skip to main content
The plugin contract a Studio plugin implements — the context, contribution types, and the compatibility gate.
Properties Related: RequiredCapabilities

​
PageContribution

Properties Related: PluginPageProps, RequiredCapabilities

​
PluginContext

The registration surface a plugin receives in its register(context) entry. Each method binds the contribution to the plugin the host is loading — the plugin’s identity is fixed by the host, not read from any ambient state — so a contribution can never be misattributed to another plugin. Contributions are staged and committed together once register settles; a register that throws commits nothing. The context is SEALED once register settles: a call made after that (a deferred timer, a post-resolve microtask) throws instead of silently dropping, so every registration must happen during register. Properties Related: NavEntryContribution, PageContribution, SettingsTabContribution, ToolPanelContribution

​
PluginContributions

Everything a single plugin bundle has registered at import time. Properties Related: RegisteredNavEntry, RegisteredPage, RegisteredSettingsTab, ToolPanelContribution

​
PluginEntry

A plugin bundle’s entry: the default plugin API. The host imports the bundle, reads its register export, and calls it with a PluginContext. All contributions flow through that context — there are no free registration functions. The entry may be synchronous or async; the host awaits it before committing, so an async entry must complete every registration before it resolves (see the seal on PluginContext). Related: PluginContext

​
PluginPageProps

Props a contributed full page receives. Navigation is via shell route tokens. Properties

​
RegisteredNavEntry

A nav entry as stored in the registry: the plugin’s NavEntryContribution plus the id of the plugin that registered it. The pluginId is stamped by the registry from the identity the host passed to PluginEntry, so the entry links only under its owner’s /plugins/{pluginId}/ prefix and two plugins may register the same path without colliding. Properties Related: NavEntryContribution, RequiredCapabilities

​
RegisteredPage

A page as stored in the registry: the plugin’s PageContribution plus the id of the plugin that registered it. The pluginId is stamped by the registry from the identity the host passed to PluginEntry — a plugin never supplies its own id — so a page resolves only under its owner’s /plugins/{pluginId}/ prefix and two plugins may register the same path without colliding. Properties Related: PageContribution, PluginPageProps, RequiredCapabilities

​
RegisteredSettingsTab

A settings tab as stored in the registry: the plugin’s SettingsTabContribution plus the id of the plugin that registered it. The pluginId is stamped by the registry from the identity the host passed to PluginEntry — a plugin never supplies its own id — so a tab is always attributable to its owner and two plugins may register the same tab id without colliding. Properties Related: RequiredCapabilities, SettingsTabContribution, SettingsTabProps

​
RequiredCapabilities

A capability requirement a contribution may declare. routes is a list of route-path prefixes (anyOf semantics, the same evaluator the shell nav uses): the contribution renders iff the caller’s capability projection covers at least one of them. ABSENT (the field is optional) means the contribution renders only for a FULL projection — safe-by-default for every existing plugin, which never declared a requirement. The server remains the authority; this only shapes what the UI advertises. Properties

​
STUDIO_PLUGIN_API_VERSION

The Studio-plugin API compatibility version. A monotonic integer bumped ONLY on a breaking change to the Studio-plugin API OR the public prop/type surface of any DS component the SDK exports (a prop rename/removal bumps it; genuinely internal/visual changes do not). Gate rule: equality is correct precisely because additive changes never bump (existing plugins keep matching) and after a break every plugin must rebuild by design. targeted == current accepts; anything else rejects. Additive evolution under this gate: a host that gains a NEW optional context capability (a new register* method, a new host-side injection behavior) keeps the same version, so every existing plugin loads unchanged. The one asymmetry the equality gate leaves is a plugin that USES a newer capability on an OLDER host that lacks it — and it fails loudly, by construction, not by any negotiation machinery:
  • A plugin calling a context method the host does not define throws the natural context.<method> is not a function during register; the loader catches it as that plugin’s loud error card and commits nothing.
  • A plugin shipping a .css asset to a host that does not inject stylesheets is served but never injected — the page renders with SDK-component styling only. This is the single quiet degradation the mechanism admits, and the authoring docs state it: stylesheet injection is a host capability, so a deployment pairs the Studio host with plugins built for it.

​
SettingsTabContribution

Properties Related: RequiredCapabilities, SettingsTabProps

​
SettingsTabProps

Props a contributed settings tab receives. Properties

​
ToolPanelContribution

Properties Related: ToolPanelProps

​
ToolPanelProps

Props a contributed tool-run panel receives (replaces the auto-form). Properties

​
VersionGateResult

Properties

​
checkPluginApiVersion

Accept iff the plugin’s targeted version exactly equals the host’s. Parameters Related: VersionGateResult