Plugin files

VitNode reads a plugin's content types from several small files instead of one big config. A different part of the app loads each file, so a public page never downloads the AdminCP's forms and a browser never sees your database code. First content type writes each file step by step; this page is the lookup.

Files at a glanceCopy Anchor Link

A content type with an AdminCP screen needs an entry in both admin/nav and admin/content. The first adds the sidebar link, the second the screen behind it. They are separate files so the sidebar stays small on every AdminCP page, while form and editor code loads only with the screen.

Without custom cells, fields or layouts, admin/content can re-export the nav list:

export { adminNav as adminContent } from "./nav";

Once you customize a screen, build adminContent on its own and reuse the nav entries, as the example plugin does:

import type { ContentFrontendPluginSource } from "@vitnode/core/lib/plugin";

import { CONFIG_PLUGIN } from "@/const";

import { exampleArticleNav, exampleCategoryNav, examplePageNav } from "./nav";

export const adminContent = {
  pluginId: CONFIG_PLUGIN.pluginId,
  contentTypes: [exampleArticleNav, exampleCategoryNav, examplePageNav],
} satisfies ContentFrontendPluginSource;

How the app finds themCopy Anchor Link

The app never imports these files by hand. Its Vite plugin resolves a fixed subpath of every plugin listed in vitnode.config.ts and writes the result into a generated file:

This happens each time vite dev or vite build starts, and the dev server regenerates the files when a resolved module changes. A subpath that does not resolve is skipped without an error, because most plugins have no content types. That is also the usual reason a new screen does not show up: a wrong file path, a wrong export name, or a plugin that was not rebuilt.

Resolution only works when the plugin id equals the npm package name and the package exports its dist folder. A generated plugin already has the right exports:

{
  "name": "@vitnode/example",
  "exports": {
    "./locales/*.json": "./src/locales/*.json",
    "./*": {
      "import": "./dist/src/*.js",
      "types": "./dist/src/*.d.ts",
      "default": "./dist/src/*.js"
    }
  }
}

Tables are the exception. Drizzle Kit reads node_modules/<pluginId>/dist/src/database/*.js directly for every plugin in the API config. Export each table from those files, or it never reaches a migration. Database shows a model with several tables.

Keep config.tsx smallCopy Anchor Link

config.tsx is bundled with the document shell of every public page:

import { buildPlugin } from "@vitnode/core/lib/plugin";

import { CONFIG_PLUGIN } from "@/const";

import messages from "./locales";
import { routes } from "./routes";

export const examplePlugin = () =>
  buildPlugin({
    ...CONFIG_PLUGIN,
    localeFiles: {
      en: "@vitnode/example/locales/en.json",
    },
    messages,
    routes,
  });

Do not import admin/nav or admin/content here. The app loads admin/nav with the AdminCP layout and admin/content behind a dynamic import(), so form code arrives only with the screen that needs it. Pulling them into config.tsx would put the whole editing stack, rich text editor included, into every public page.

localeFiles maps each language to your locale JSON so the app can load it. Without it nothing fails, but every label from your locale file is missing.

content.ts and public URLsCopy Anchor Link

A content type with delivery or search publishes URLs. List every such content type in src/content.ts. The example plugin lists all of its types, which is allowed:

import { advancedArticleContentType } from "@/content/advanced-article";
import { articleContentType } from "@/content/article";
import { categoryContentType } from "@/content/category";
import { localizedArticleContentType } from "@/content/localized-article";
import { pageContentType } from "@/content/page";

export const contentTypes = [
  articleContentType,
  advancedArticleContentType,
  localizedArticleContentType,
  categoryContentType,
  pageContentType,
];

Keep the module browser-safe: it imports definitions only, never src/database. The web build checks that one of your pages serves each URL, and the API refuses to start when a plugin publishes URLs that this module does not declare. See Content URLs need a page.

ErrorsCopy Anchor Link