Extension reference
Migrate from 0.x
Version 1 replaces the experimental raw channel with one shared, schema-validated protocol and consistent renderer context names. Update both package entries together.
Migration checklist
- Add the literal
apiVersion: 1todefineRenderer. - Define one protocol with
defineProtocol. - Pass that protocol to both
defineRendererandconnect. - Replace individual raw method registration with the complete handler table passed to
connect. - Rename
NativePiContexttoRendererContext. - Rename renderer prop
ctxtocontext. - Move
ctx.callandctx.onundercontext.channel. - Rename array contribution
keyfields toid. - Read project, session, and agent state from their dedicated context fields.
- Delete guards that duplicate the new runtime schemas.
Replace the raw channel
import { defineProtocol } from "@nativepi/extension-api";
import { z } from "@nativepi/extension-api/schema";
export const protocol = defineProtocol({
methods: {
state: { result: z.object({ enabled: z.boolean() }) },
setEnabled: {
params: z.object({ enabled: z.boolean() }),
result: z.object({ enabled: z.boolean() }),
},
},
events: {
changed: z.object({ enabled: z.boolean() }),
},
});Replace method registration
Instead of registering methods one at a time, connect the whole table. A reload then replaces removed methods rather than leaving them behind.
const channel = connect("@acme/package");
channel.method("state", () => state);
channel.method("setEnabled", update);const host = connect("@acme/package", protocol, {
state: () => state,
setEnabled: update,
});Update renderer context
render: (ctx) => {
ctx.call("state");
ctx.on("changed", update);
return <Panel project={ctx.session?.cwd} />;
}render: (context) => {
context.channel.call("state");
context.channel.on("changed", update);
return <Panel project={context.project.path} />;
}The old nullable session object is now a stable shape. A new chat uses context.session.file: null. The old dark flag was removed because renderers style against semantic color variables, which update with NativePi's light, dark, and custom appearances.
Load behavior
NativePi rejects a 0.x renderer before running any contribution and reports a compatibility error. The package's ordinary Pi extension still loads, so terminal behavior and non-graphical tools remain available during migration.