Plugin routes and UI extensions

The plugin package supports navigation metadata, extension slots, widgets, middleware types, breadcrumbs, and an App Router-style routeTree contract. The host integration determines how route definitions are discovered and mounted.

UI extensions#

A plugin extension has an ID, target, extension point, React component, and optional priority, metadata, roles, and permissions. A widget has an ID, name, area, component, and optional layout/authorization metadata.

import type { IPlugin } from "@veap/plugins";

export const reportsPlugin: IPlugin = {
  manifest: {
    id: "example-reports",
    name: "Reports",
    version: "1.0.0",
    enabled: true,
  },
  extensions: [
    {
      id: "reports-header-action",
      target: "admin-header",
      point: "header:actions",
      component: ReportsHeaderAction,
      priority: 20,
    },
  ],
};

Use the extension point names recognized by your host application. An arbitrary string does not create a slot automatically; the consuming UI must render the matching extension slot.

Client imports#

React UI components and extension slots belong in client-capable code and should be imported from @veap/plugins/client where supported. Keep database, auth services, and privileged plugin handlers in server-only modules.

Route trees#

The IPlugin contract permits a routeTree value or async function returning a route node. This is an integration contract, not a replacement for Next.js file routing. Confirm how the host discovers routes, loads modules, and handles layouts, loading/error boundaries, and dynamic segments before relying on those behaviors.

Authorization#

roles and permissions metadata can hide or filter navigation and extensions. Always repeat authorization on the server when a user invokes the underlying action or route.