Metadata
Who your mod is, for the gallery and for the person installing it. The one key
on Mod that describes rather than contributes.
import { function defineMod<const TMod extends ModDefinition>(definition: TMod & ValidateModHooks<TMod>): ModThe entry point of the SDK. A mod's module default-exports one `defineMod` call and nothing else. The returned value is data. It registers nothing, starts nothing, and touches no host state. The host folds it twice. At build time it runs the module in a throwaway sandbox and reads the value to derive the serializable manifest. At runtime it folds the same value again to wire your handlers into their lanes: ext-host for commands, tools, effects, and hooks; the sandboxed renderer for views and widgets. That double fold is why the module must be pure. It is re-executed to produce the manifest, so anything at the top level, a file read, a network call, a timer, a `console` line, runs during a build with no host attached. Put behavior inside handlers: `run`, `activate`, `handle`. The `ValidateModHooks` constraint makes the call fail to typecheck when a `hook.beforeAction` targets an action that is neither a known host action nor `command:` plus one of this mod's own command ids.defineMod } from '@modular/sdk'; export defaultdefineMod<{ readonly metadata: { readonly displayName: "Hello"; readonly description: "A first mod"; readonly categories: readonly ["Other"]; }; }>(definition: { readonly metadata: { readonly displayName: "Hello"; readonly description: "A first mod"; readonly categories: readonly ["Other"]; }; }): ModThe entry point of the SDK. A mod's module default-exports one `defineMod` call and nothing else. The returned value is data. It registers nothing, starts nothing, and touches no host state. The host folds it twice. At build time it runs the module in a throwaway sandbox and reads the value to derive the serializable manifest. At runtime it folds the same value again to wire your handlers into their lanes: ext-host for commands, tools, effects, and hooks; the sandboxed renderer for views and widgets. That double fold is why the module must be pure. It is re-executed to produce the manifest, so anything at the top level, a file read, a network call, a timer, a `console` line, runs during a build with no host attached. Put behavior inside handlers: `run`, `activate`, `handle`. The `ValidateModHooks` constraint makes the call fail to typecheck when a `hook.beforeAction` targets an action that is neither a known host action nor `command:` plus one of this mod's own command ids.defineMod({metadata: { readonly displayName: "Hello"; readonly description: "A first mod"; readonly categories: readonly ["Other"]; }metadata: { displayName: "Hello"displayName: 'Hello', description: "A first mod"description: 'A first mod', categories: readonly ["Other"]categories: ['Other'], }, });
Members
ModMetadata — displayName,
description, categories, keywords, icon, preview, license,
homepage, repository, bugs.
| Group | Members |
|---|---|
| what it is | displayName description icon preview |
| how it is found | categories keywords |
| where it comes from | homepage repository license bugs |
Two of those have their own shapes:
ModRepository — type, url — and
ModBugs — url, email.
Categories are a fixed set
categories takes values from
ModCategory, a closed union — AI,
Chat, Data Science, Debuggers, Education, Extension Packs,
Formatters, Keymaps, Language Packs, Linters, and the rest. You cannot
invent one, which is what keeps the gallery navigable.
No id here
There is no id in ModMetadata. A mod's identity comes from its package, not
from a field you set — so displayName is free to change without breaking
anything that points at your mod.