@lunarisapp/plugin-sdk

Public TypeScript and React SDK for building Lunaris extensions.

Supported entry points:

• @lunarisapp/plugin-sdk
• @lunarisapp/plugin-sdk/data
• @lunarisapp/plugin-sdk/time
• @lunarisapp/plugin-sdk/worker
• @lunarisapp/plugin-sdk/catalog
• @lunarisapp/plugin-sdk/mcp
• @lunarisapp/plugin-sdk/sandbox (host build runtime)
• @lunarisapp/plugin-sdk/vite (Node-only build tooling)

Community extensions can call usePluginFetch() for unauthenticated HTTPS requests. Browser extensions remain subject to CORS; desktop uses the native HTTP transport. Credentials default to omit on both platforms.

Extension repositories build through standard Vite configuration:

import { defineLunarisPluginConfig } from "@lunarisapp/plugin-sdk/vite";

export default defineLunarisPluginConfig();

Running vite build emits the normalized manifest and self-contained sandbox IIFE expected by Lunaris. The helper enforces import boundaries, asset limits, and release-tag compatibility. An optional root-level icon.<extension> file may use any detectable raster format, including PNG, WebP, JPEG, GIF, and AVIF; the build validates it and preserves its extension. Catalog extensions run in opaque-origin iframes; see sandbox security.

Use runPluginWorkerTask and exposePluginWorkerTask from the /worker entry point for one-shot CPU-heavy work. External extensions must import their dedicated worker with Vite's ?worker&inline query so the release remains one hash-pinned script.

SDK 0.9 resources compose named Yjs, key-value, and single-file slots. Views declare only the subset they consume. See storage, resources, views, and the 0.9 migration guide.

@lunarisapp/plugin-sdk/internal exists only for the official Lunaris host and does not follow public semantic-versioning guarantees.

Protocol 7, incremental Yjs hydration, and chunked downloads are documented in the API 0.10 / SDK 0.11 migration guide.