Merge pull request #790 from aXenDeveloper/feat/homepage-redesign-blue

feat: Add home page by fable

Author: aXenDeveloper

apps/api/package.json

@@ -10,7 +10,7 @@
     "dev": "vitnode db:prepare && tsx watch src/index.ts",
     "dev:email": "email dev --dir src/emails",
     "build": "tsc && tsc-alias -p tsconfig.json",
-    "start": "node dist/index.js",
+    "start": "node dist/src/index.js",
     "drizzle-kit": "drizzle-kit",
     "lint": "eslint .",
     "lint:fix": "eslint . --fix",

apps/web/content/docs/dev/configuration.mdx

@@ -77,11 +77,13 @@ import { blogPlugin } from '@vitnode/blog/config'
 plugins: [blogPlugin()]
 ```
 
-The factory carries the plugin's content types, its AdminCP navigation and its
-translations - one declaration, and the same one a Next.js host reads directly.
+The factory carries the plugin's identity, its locale barrel and its route
+declarations - plain data, and nothing that renders. Its AdminCP navigation and
+its Content Engine screens live in the plugin's `admin/nav` and `admin/content`
+modules instead, and they never pass through this object.
 
 What a TanStack Start app **renders** comes back through generated projections
-rather than out of this object, and that is the part worth knowing:
+of those modules, and that is the part worth knowing:
 
 | Generated file                | From                         | Loaded                                          |
 | :---------------------------- | :--------------------------- | :---------------------------------------------- |
@@ -92,7 +94,9 @@ rather than out of this object, and that is the part worth knowing:
 One literal import per configured plugin, written at build time. So a content
 type's editing screen - a Tiptap field, a form layout, a table cell - arrives
 with the route that renders it, not with the config that the document shell
-imports. See [Plugin routes](/docs/dev/plugins/routes) and
+imports. Spreading `admin/content` into the factory undoes exactly that: the
+whole editing stack rides along with every public page. See
+[Plugin routes](/docs/dev/plugins/routes) and
 [Plugin frontend modules](/docs/dev/content-engine/plugin-registration).
 
 <Callout type="info" title="Also register its locale files">
@@ -246,14 +250,19 @@ import { vitnode } from '@vitnode/core/framework/vite'
 export default defineConfig({
   plugins: [
     vitnode({ appRoot: import.meta.dirname }),
-    nitro(),
+    nitro({ compressPublicAssets: { brotli: true, gzip: true } }),
     tailwindcss(),
     tanstackStart(),
     viteReact(),
   ],
 })
 ```
 
+`compressPublicAssets` writes a `.br` and a `.gz` twin next to every built asset,
+so the Node server from `pnpm start` serves scripts and styles compressed the
+way a CDN would. The server-rendered HTML itself is not compressed by the Node
+server; put a reverse proxy or a platform such as Vercel in front of it for that.
+
 `appRoot` has to be `import.meta.dirname`: a Vite config is loaded with the
 working directory set to wherever the command ran, which in a monorepo is
 regularly the repository root.

apps/web/content/docs/dev/content-engine/admincp.mdx

@@ -4,33 +4,37 @@ description: Configure zero-code AdminCP management screens, custom form layouts
 icon: LayoutDashboard
 ---
 
-import { TypeTable } from "fumadocs-ui/components/type-table"
+import { TypeTable } from 'fumadocs-ui/components/type-table'
 
 Content Engine automatically builds interactive management screens in the AdminCP without writing hand-rolled pages or form components.
 
 ## Quick start
 
-Register your content type in `src/config.tsx` with `contentTypeAdmin`:
-
-```tsx title="plugins/blog/src/config.tsx"
-import { buildPlugin, contentTypeAdmin } from "@vitnode/core/lib/plugin"
-import { FileTextIcon } from "lucide-react"
-import { postContentType } from "./content/post"
-
-export const blogPlugin = () =>
-  buildPlugin({
-    pluginId: "blog",
-    // [!code ++:6]
-    contentTypes: [
-      contentTypeAdmin({
-        definition: postContentType,
-        icon: <FileTextIcon />,
-      }),
-    ],
-  })
+Register your content type in `src/admin/content.tsx` with `contentTypeAdmin`:
+
+```tsx title="plugins/blog/src/admin/content.tsx"
+import type { ContentFrontendPluginSource } from '@vitnode/core/lib/plugin'
+import { contentTypeAdmin } from '@vitnode/core/lib/plugin'
+import { FileTextIcon } from 'lucide-react'
+import { postContentType } from '@/content/post'
+
+export const adminContent = {
+  pluginId: 'blog',
+  // [!code ++:6]
+  contentTypes: [
+    contentTypeAdmin({
+      definition: postContentType,
+      icon: <FileTextIcon />,
+    }),
+  ],
+} satisfies ContentFrontendPluginSource
 ```
 
-The screen is immediately accessible at `/admin/content/blog/post`.
+The screen is immediately accessible at `/admin/content/blog/post`. The build
+imports this module for you through the generated content registry; keep it out
+of `config.tsx`, which is bundled with every public page. See
+[Plugin frontend modules](/docs/dev/content-engine/plugin-registration) for the
+matching `admin/nav.tsx` sidebar entry.
 
 ---
 
@@ -40,17 +44,17 @@ Control which columns, search inputs, and sortable headers appear in the AdminCP
 
 ```ts title="plugins/blog/src/content/post.ts"
 export const postContentType = defineContentType({
-  id: "blog.post",
-  tableName: "blog_posts",
-  fields: { /* ... */ },
+  id: 'blog.post',
+  tableName: 'blog_posts',
+  fields: {/* ... */},
   // [!code ++:9]
   admin: {
-    titleField: "title", // Primary record identifier in dialogs
+    titleField: 'title', // Primary record identifier in dialogs
     list: {
-      columns: ["title", "status", "author", "createdAt"],
-      searchableFields: ["title"],
-      orderableFields: ["title", "createdAt"],
-      defaultOrderBy: { column: "createdAt", order: "desc" },
+      columns: ['title', 'status', 'author', 'createdAt'],
+      searchableFields: ['title'],
+      orderableFields: ['title', 'createdAt'],
+      defaultOrderBy: { column: 'createdAt', order: 'desc' },
     },
   },
 })
@@ -94,7 +98,7 @@ replaces it.
 The placeholder is built from the content type's definition, so it needs no
 configuration - a `text` field becomes an input-sized block, a `boolean` becomes
 a switch, a `file` becomes a media box, and a to-many picker becomes a list. If
-you gave the content type its own layout, the placeholder renders *that* layout,
+you gave the content type its own layout, the placeholder renders _that_ layout,
 so the fields land exactly where they will a moment later.
 
 ### When an override is a different shape
@@ -109,7 +113,7 @@ contentTypeAdmin({
   fields: {
     content: {
       component: BlogArticleEditorField,
-      skeleton: "editor", // [!code ++]
+      skeleton: 'editor', // [!code ++]
     },
   },
 })
@@ -128,10 +132,10 @@ contentTypeAdmin({
 The same block is available on its own, for a field that lazy-loads its control:
 
 ```tsx title="plugins/blog/src/views/admin/article/editor-field.tsx"
-import { ContentFormFieldSkeleton } from "@vitnode/core/content/admin-form"
+import { ContentFormFieldSkeleton } from '@vitnode/core/content/admin-form'
 
 ;<React.Suspense fallback={<ContentFormFieldSkeleton control="editor" />}>
-  <AutoFormEditor label={t("content.label")} {...props} />
+  <AutoFormEditor label={t('content.label')} {...props} />
 </React.Suspense>
 ```
 

apps/web/content/docs/dev/content-engine/defining-a-content-type.mdx

@@ -4,9 +4,9 @@ description: Declare a Content Engine content type once to get a Postgres table,
 icon: FileCode
 ---
 
-import { File, Files, Folder } from "fumadocs-ui/components/files"
-import { Tab, Tabs } from "fumadocs-ui/components/tabs"
-import { TypeTable } from "fumadocs-ui/components/type-table"
+import { File, Files, Folder } from 'fumadocs-ui/components/files'
+import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
+import { TypeTable } from 'fumadocs-ui/components/type-table'
 
 Content Engine generates a complete CRUD ecosystem from one declaration: a PostgreSQL table, Zod validation schemas, API endpoints, staff permissions, and AdminCP management screens.
 
@@ -15,23 +15,23 @@ Content Engine generates a complete CRUD ecosystem from one declaration: a Postg
 ### 1. Define the Content Type
 
 ```ts title="plugins/example/src/content/category.ts"
-import { defineContentType, field } from "@vitnode/core/content"
+import { defineContentType, field } from '@vitnode/core/content'
 
 export const categoryContentType = defineContentType({
-  id: "example.category",
-  tableName: "example_categories",
+  id: 'example.category',
+  tableName: 'example_categories',
   fields: {
     name: field.text({ required: true, minLength: 2, maxLength: 100 }),
-    slug: field.slug({ from: "name", required: true }),
+    slug: field.slug({ from: 'name', required: true }),
   },
 })
 ```
 
 ### 2. Create the Database Model
 
 ```ts title="plugins/example/src/database/categories.ts"
-import { createContentModel } from "@vitnode/core/content/server"
-import { categoryContentType } from "@/content/category"
+import { createContentModel } from '@vitnode/core/content/server'
+import { categoryContentType } from '@/content/category'
 
 export const categoryContent = createContentModel(categoryContentType)
 export const example_categories = categoryContent.table
@@ -69,16 +69,14 @@ Your table now exists in PostgreSQL.
 Add the model to your plugin's `config.api.ts`:
 
 ```ts title="plugins/example/src/config.api.ts"
-import { buildApiPlugin } from "@vitnode/core/api/lib/plugin"
-import { categoryContent } from "./database/categories"
+import { buildApiPlugin } from '@vitnode/core/api/lib/plugin'
+import { categoryContent } from './database/categories'
 
 export const exampleApiPlugin = () =>
   buildApiPlugin({
-    pluginId: "@vitnode/example",
+    pluginId: '@vitnode/example',
     // [!code ++:3]
-    contentTypes: [
-      categoryContent,
-    ],
+    contentTypes: [categoryContent],
   })
 ```
 
@@ -89,26 +87,30 @@ This immediately registers full CRUD routes under `/api/@vitnode/example/admin/c
 
 ### 2. Register Screens in the AdminCP
 
-Connect the definition in `src/config.tsx`:
-
-```tsx title="plugins/example/src/config.tsx"
-import { buildPlugin, contentTypeAdmin } from "@vitnode/core/lib/plugin"
-import { FolderIcon } from "lucide-react"
-import { categoryContentType } from "./content/category"
-
-export const examplePlugin = () =>
-  buildPlugin({
-    pluginId: "@vitnode/example",
-    // [!code ++:6]
-    contentTypes: [
-      contentTypeAdmin({
-        definition: categoryContentType,
-        icon: <FolderIcon />,
-      }),
-    ],
-  })
+Connect the definition in `src/admin/content.tsx`. The build imports this module
+through the generated content registry, so it never reaches a public page:
+
+```tsx title="plugins/example/src/admin/content.tsx"
+import type { ContentFrontendPluginSource } from '@vitnode/core/lib/plugin'
+import { contentTypeAdmin } from '@vitnode/core/lib/plugin'
+import { FolderIcon } from 'lucide-react'
+import { categoryContentType } from '@/content/category'
+
+export const adminContent = {
+  pluginId: '@vitnode/example',
+  // [!code ++:6]
+  contentTypes: [
+    contentTypeAdmin({
+      definition: categoryContentType,
+      icon: <FolderIcon />,
+    }),
+  ],
+} satisfies ContentFrontendPluginSource
 ```
 
+The sidebar entry comes from `src/admin/nav.tsx` the same way - see
+[Plugin frontend modules](/docs/dev/content-engine/plugin-registration).
+
 </Step>
 <Step>
 
@@ -151,25 +153,26 @@ You have a complete AdminCP data table with search, sorting, pagination, and mod
     id: {
       description: "Unique identifier formatted as '<plugin>.<name>'.",
       required: true,
-      type: "string",
+      type: 'string',
     },
     tableName: {
       description: "Postgres table name (e.g. 'example_categories').",
       required: true,
-      type: "string",
+      type: 'string',
     },
     fields: {
-      description: "Record containing field descriptors created with field.*.",
+      description: 'Record containing field descriptors created with field.*.',
       required: true,
-      type: "Record<string, ContentField>",
+      type: 'Record<string, ContentField>',
     },
     publication: {
-      description: "Enables draft/published workflows and publishedAt timestamps.",
-      type: "{ enabled: boolean }",
+      description:
+        'Enables draft/published workflows and publishedAt timestamps.',
+      type: '{ enabled: boolean }',
     },
     indexes: {
-      description: "Custom single or composite database indexes.",
-      type: "IndexDefinition[]",
+      description: 'Custom single or composite database indexes.',
+      type: 'IndexDefinition[]',
     },
   }}
 />