create-vitnode-app 2.0.0-canary.1 → 2.0.0-canary.11

package/README.md

@@ -59,8 +59,14 @@ pnpm create vitnode-app@latest --plugin
 npm create vitnode-app@latest -- --plugin
 ```
 
-The generator creates the package and adds its workspace dependency. Register it
-in the host’s `vitnode.config.ts` to enable the feature.
+The generator creates the package and adds its workspace dependency. Enable the
+feature by registering it in the host’s `vitnode.config.ts`:
+
+```ts
+import { myPlugin } from '@acme/my-plugin/config'
+
+plugins: [myPlugin()]
+```
 
 ## Options
 
@@ -69,6 +75,7 @@ in the host’s `vitnode.config.ts` to enable the feature.
 | `--package-manager` | Choose `npm` or `pnpm` for the generated project. |
 | `--eslint` | Include ESLint and Prettier configuration. |
 | `--skip-install` | Skip dependency installation after scaffolding. |
+| `--skip-git` | Skip initializing a git repository (created on `main` after install). |
 | `--mode` | Choose `singleApp`, `apiMonorepo`, or `onlyApi`. |
 | `--monorepo` | Create a workspace layout for plugins and multiple applications. |
 | `--docker` | Include local Docker services. |

package/copy-of-vitnode-app/README.md

@@ -38,3 +38,25 @@ To start the development server, run the following command:
 ```bash
 pnpm dev
 ```
+
+## Configuration
+
+Two files, and the line between them is one question: may a browser hold this?
+
+| File                           | Holds                                                                                                                    |
+| :----------------------------- | :----------------------------------------------------------------------------------------------------------------------- |
+| `src/vitnode.config.ts`        | locales, metadata, theme, `debug`, enabled plugin ids - plain data, read by the browser, the server, and your Vite build |
+| `src/vitnode.server.config.ts` | message loaders - server only                                                                                            |
+
+Add a language to `i18n.locales` in the shared config; register the files that
+translate it in `src/locales/packages.ts` (a package's own translations) or
+`src/locales/app.ts` (your rewordings). `pnpm vitnode i18n:create de Deutsch`
+does all three.
+
+`src/start.ts` is one call to `createVitNodeStart`, which installs CSRF
+protection for server functions, canonical locale redirects with the
+remembered-locale cookie, and the `private, no-store` directive every rendered
+document needs. Add your own request middleware with `requestMiddleware` - it
+runs after all of it.
+
+See [Configuration](https://vitnode.com/docs/dev/configuration).

package/copy-of-vitnode-app/api/src/vitnode.api.config.ts

@@ -3,8 +3,6 @@ import { config } from "dotenv";
 import { coreRelations } from "@vitnode/core/database/relations";
 import { drizzle } from "drizzle-orm/postgres-js";
 
-import { i18n } from "./i18n.js";
-
 config({
   quiet: true,
 });
@@ -14,15 +12,16 @@ export const POSTGRES_URL =
 
 export const vitNodeApiConfig = buildApiConfig({
   plugins: [],
-  /**
-   * The installation's languages - see `src/i18n.ts`, and keep it in step with
-   * the web app's file of the same name.
-   *
-   * This app owns the schema, so `vitnode db:prepare` seeds `core_languages`
-   * from this list. Leave it out and the seed falls back to `en` alone, whatever
-   * the site serves.
-   */
-  i18n,
+  
+  i18n: {
+    defaultLocale: "en",
+    locales: [{ code: "en", name: "English" }],
+    /**
+     * Explicit, because this API renders emails on a server: without one, dates
+     * format in whatever zone the host happens to run in.
+     */
+    timeZone: "UTC",
+  },
   dbProvider: drizzle({
     connection: POSTGRES_URL,
     relations: coreRelations,

package/copy-of-vitnode-app/api-single-app/src/routes/api/$.ts

@@ -1,32 +1,10 @@
-import { createFileRoute } from '@tanstack/react-router'
+import { createFileRoute } from "@tanstack/react-router";
 
-import { apiBridge } from '#/server/vitnode-api.server'
+import { apiBridge } from "@/server/vitnode-api.server";
 
-/**
- * `/api/*` - the existing VitNode Hono application, mounted.
- *
- * `server` is the only option on this route on purpose. TanStack Start prunes a
- * route file whose sole option is `server` out of the client route tree
- * entirely (and its client code-splitter deletes the `server` node on top of
- * that), so none of the API - Hono, Drizzle, the plugins - can reach the browser
- * bundle. The `.server.ts` import is refused by import protection if that ever
- * stops being true.
- *
- * `ANY` rather than a handler per method: routing, OpenAPI, middleware, auth,
- * plugin mounting and error handling all stay inside Hono, exactly as they are
- * when the same app runs standalone in `apps/api` or under the Next.js catch-all
- * in `apps/docs`. `ANY` is part of the framework's `RouteMethod` union and is
- * what Start falls back to for any method it was given no handler for - `HEAD`
- * included, where it calls this handler and strips the response body itself.
- * So the API keeps answering for methods this file has never heard of, which is
- * the point: there is nothing here to keep in sync with the API's routes.
- *
- * `src/tests/api-server-route.test.ts` drives the real request handler over this
- * route to hold that to every method the API needs.
- */
-export const Route = createFileRoute('/api/$')({
+export const Route = createFileRoute("/api/$")({
   server: {
     handlers: ({ createHandlers }) =>
       createHandlers({ ANY: async ({ request }) => apiBridge(request) }),
   },
-})
+});

package/copy-of-vitnode-app/api-single-app/src/server/api-bridge.ts

@@ -1,15 +1,4 @@
-/**
- * The seam between the web runtime and the Hono API.
- *
- * A bridge is handed the `Request` the browser (or an SSR loader) made to
- * `/api/*` on this origin and answers it with whatever Hono answers. It is one
- * line, and that is the point: status, body, every `Set-Cookie`, the cookie and
- * `x-forwarded-*` headers the API reads are all already correct on the request
- * the platform built, and stay correct exactly as long as nobody rebuilds them.
- *
- * `src/tests/api-bridge-contract.ts` holds this to that behaviour, including the
- * ways a rebuilt request loses it.
- */
+
 export type ApiBridge = (request: Request) => Promise<Response> | Response
 
 interface FetchableApp {

package/copy-of-vitnode-app/api-single-app/src/server/vitnode-api.server.ts

@@ -1,29 +1,29 @@
-import '@tanstack/react-start/server-only'
-import { OpenAPIHono } from '@hono/zod-openapi'
-import { VitNodeAPI } from '@vitnode/core/api/config'
+import "@tanstack/react-start/server-only";
+import { OpenAPIHono } from "@hono/zod-openapi";
+import { VitNodeAPI } from "@vitnode/core/api/config";
 
-import { createApiBridge } from '#/server/api-bridge'
-import { vitNodeApiConfig } from '#/vitnode.api.config'
+import { createApiBridge } from "@/server/api-bridge";
+import { vitNodeApiConfig } from "@/vitnode.api.config";
 
 // The same two lines `apps/api` and `apps/docs` run. `basePath("/api")` is what
 // makes the mount point part of the API's own routing, so every path the plugins
 // register - `/api/@vitnode/core/...` - resolves identically here.
 const createVitNodeApi = () => {
-  const app = new OpenAPIHono().basePath('/api')
+  const app = new OpenAPIHono().basePath("/api");
 
-  VitNodeAPI({ app, vitNodeApiConfig })
+  VitNodeAPI({ app, vitNodeApiConfig });
 
-  return app
-}
+  return app;
+};
 
 // `VitNodeAPI` is a boot step, not a request step: it opens the Redis client,
 // starts the cron scheduler and registers every plugin route. Vite re-evaluates
 // server modules on HMR, so the instance is parked on `globalThis` to keep one
 // API per process instead of one per edit.
 const cache = globalThis as typeof globalThis & {
-  __vitnodeApi?: ReturnType<typeof createVitNodeApi>
-}
+  __vitnodeApi?: ReturnType<typeof createVitNodeApi>;
+};
 
-export const vitNodeApi = (cache.__vitnodeApi ??= createVitNodeApi())
+export const vitNodeApi = (cache.__vitnodeApi ??= createVitNodeApi());
 
-export const apiBridge = createApiBridge(vitNodeApi)
+export const apiBridge = createApiBridge(vitNodeApi);

package/copy-of-vitnode-app/api-single-app/src/vitnode.api.config.ts

@@ -2,7 +2,7 @@ import { buildApiConfig } from "@vitnode/core/vitnode.config";
 import { coreRelations } from "@vitnode/core/database/relations";
 import { drizzle } from "drizzle-orm/postgres-js";
 
-import { i18n } from "./i18n";
+import { vitNodeConfig } from "./vitnode.config";
 
 export const POSTGRES_URL =
   process.env.POSTGRES_URL ?? "postgresql://root:root@localhost:5432/vitnode";
@@ -13,17 +13,8 @@ export const vitNodeApiConfig = buildApiConfig({
     shortTitle: "VitNode",
   },
   plugins: [],
-  /**
-   * The same `src/i18n.ts` the frontend config reads, because this app is both:
-   * one declaration of which languages exist, spread into `buildConfig` through
-   * `vitnode.shell.config.ts` and passed here.
-   *
-   * It is also what `vitnode db:prepare` seeds `core_languages` from - this app
-   * owns the schema - so adding a language here and re-running `dev` inserts its
-   * row. Leave it out and the seed falls back to `en` alone, whatever the site
-   * serves.
-   */
-  i18n,
+  
+  i18n: vitNodeConfig.i18n,
   dbProvider: drizzle({
     connection: POSTGRES_URL,
     relations: coreRelations,

package/copy-of-vitnode-app/docker/docker-compose.yml

@@ -1,5 +1,3 @@
-version: '3.8'
-
 services:
   database:
     container_name: vitnode_postgres_dev
@@ -12,7 +10,11 @@ services:
     volumes:
       - ./docker/dev:/var/lib/postgresql/data
     ports:
-      - '5432:5432'
+      # Loopback only. These are development containers with a default password
+      # of `root`, and `'5432:5432'` publishes them on every interface the host
+      # has - which on a laptop is whatever café or office network it is joined
+      # to, and on a VPS is the internet.
+      - '127.0.0.1:5432:5432'
     networks:
       - vitnode_dev
 
@@ -22,7 +24,7 @@ services:
     restart: unless-stopped
     command: redis-server --requirepass ${REDIS_PASSWORD-root}
     ports:
-      - '6379:6379'
+      - '127.0.0.1:6379:6379'
     networks:
       - vitnode_dev
 

package/copy-of-vitnode-app/monorepo/apps/api/.env.example

@@ -1,7 +1,7 @@
 POSTGRES_URL=postgresql://root:root@localhost:5432/vitnode
 REDIS_URL=redis://localhost:6379
 
-NEXT_PUBLIC_WEB_URL=http://localhost:3000
+VITNODE_WEB_URL=http://localhost:3000
 
 # === Docker Database Postgres ===
 POSTGRES_USER=root

package/copy-of-vitnode-app/monorepo/apps/web/.env.example

@@ -1,12 +1 @@
-NEXT_PUBLIC_API_URL=http://localhost:8000
-
-# Optional. Set these to back the Next.js caches with Redis, so cached pages and
-# `use cache` entries are shared between instances and a tag revalidation on one
-# instance is seen by all of them.
-#
-# The web process needs its own copy: the cache handlers are loaded by Next.js
-# itself and read the environment directly - they cannot see the API's
-# `vitnode.api.config.ts`. Point them at the same Redis the API uses.
-# https://vitnode.com/docs/dev/advanced/redis#caching-nextjs-output
-# REDIS_URL=redis://localhost:6379
-# REDIS_PASSWORD=root
+VITNODE_API_URL=http://localhost:8000

package/copy-of-vitnode-app/monorepo/turbo.json

@@ -3,6 +3,7 @@
   "ui": "tui",
   "tasks": {
     "db:prepare": {
+      "dependsOn": ["^build:plugins"],
       "cache": false,
       "inputs": ["$TURBO_DEFAULT$", ".env*"],
       "env": ["POSTGRES_URL"]
@@ -13,17 +14,21 @@
       "inputs": ["$TURBO_DEFAULT$", ".env*"],
       "env": ["POSTGRES_URL"]
     },
+    "build:plugins": {
+      "dependsOn": ["^build:plugins"],
+      "outputs": ["dist/**"]
+    },
     "build": {
-      "dependsOn": ["^build"],
+      "dependsOn": ["^build:plugins", "^build"],
       "inputs": ["$TURBO_DEFAULT$", ".env*"],
       "outputs": [".output/**", "dist/**"],
-      "env": ["POSTGRES_URL", "NEXT_PUBLIC_API_URL", "NEXT_PUBLIC_WEB_URL"]
+      "env": ["POSTGRES_URL", "VITNODE_API_URL", "VITNODE_WEB_URL"]
     },
     "dev": {
       "cache": false,
       "persistent": true,
       "inputs": ["$TURBO_DEFAULT$", ".env*"],
-      "env": ["POSTGRES_URL", "NEXT_PUBLIC_API_URL", "NEXT_PUBLIC_WEB_URL"]
+      "env": ["POSTGRES_URL", "VITNODE_API_URL", "VITNODE_WEB_URL"]
     },
     "start": {
       "dependsOn": ["^start"]

package/copy-of-vitnode-app/root/.env.example

@@ -1,14 +1,7 @@
 POSTGRES_URL=postgresql://root:root@localhost:5432/vitnode
 REDIS_URL=redis://localhost:6379
 
-# Both name this app's own origin, and it has to be the port `dev` actually
-# serves. Neither is strictly required: on the server the API origin is taken
-# off the request being rendered, and in the browser it falls back to the origin
-# the page was served from - so a preview deployment on a generated hostname
-# needs no config at all. Set `NEXT_PUBLIC_API_URL` only to point at a separate
-# API server; `NEXT_PUBLIC_WEB_URL` is what the API stamps cookies with.
-NEXT_PUBLIC_WEB_URL=http://localhost:3000
-NEXT_PUBLIC_API_URL=http://localhost:3000
+VITNODE_WEB_URL=http://localhost:3000
 
 # === CRON Secret for Internal API Calls ===
 CRON_SECRET=your-secure-cron-secret-key

package/copy-of-vitnode-app/root/global.d.ts

@@ -2,25 +2,7 @@
 
 import core from '@vitnode/core/locales/en.json' with { type: 'json' }
 
-/**
- * What `useTranslations` is allowed to be asked for.
- *
- * Augmenting **`use-intl`** rather than `next-intl`. `AppConfig` is declared by
- * `use-intl`, which is what VitNode renders every string through on every host;
- * `next-intl` only ever re-exported it. This is a type-level dependency and so
- * it survives a grep for imports - which is exactly why it is worth naming.
- *
- * `use-intl` has to be a *direct* dependency of this app for the reference above
- * to resolve. Under pnpm's strict `node_modules` layout, reaching it through
- * `@vitnode/core` is not enough.
- *
- * Typed against core's English tree, which is the default locale: every other
- * language falls back to it key by key, so it is the one that defines which keys
- * exist. Add a plugin's tree to the intersection to get its keys checked too:
- *
- *     import blog from '@acme/blog/locales/en.json' with { type: 'json' }
- *     Messages: typeof core & typeof blog
- */
+
 declare module 'use-intl' {
   interface AppConfig {
     Messages: typeof core

package/copy-of-vitnode-app/root/src/components/admin-shell.tsx

@@ -1,58 +1,8 @@
-import type { AdminUserSearch } from "@vitnode/core/tanstack/admin";
-
 import { AdminShellContent } from "@vitnode/core/tanstack/admin";
+import { useAppNavigate } from "@vitnode/core/tanstack/auth";
 import { LanguageSwitcher } from "@vitnode/core/tanstack/layout";
 
-import { adminNav } from "#/lib/admin-nav";
-import { adminUserSearchFn } from "#/lib/admin-search";
-import { useAppNavigate } from "#/lib/navigation";
-
-/**
- * The AdminCP shell, as this app mounts it.
- *
- * Everything the panel *is* - the sidebar, the header, the palette, the user
- * menu, the breadcrumb area and the one `<main>` - is `AdminShellContent`'s.
- * What is bound here is only what a package cannot answer for an application:
- *
- *     onNavigate        useAppNavigate       the palette's Enter key
- *     searchUsers       adminUserSearchFn    this app's own server function
- *     languageSwitcher  <LanguageSwitcher/>  the router's
- *     nav               adminNav             the plugins *this* app configured
- *
- * No `LinkComponent`: every sidebar destination is a route in this application's
- * own tree, so the shell's own default - `RouterLink` - is the right one. The
- * exception is handled a layer down rather than here: a plugin's `admin.nav`
- * entry may point at a docs site or a status page, and `adminLinkFor` renders
- * those as plain anchors, so an absolute URL is never handed to a router that
- * would try to match it. The sidebar and the command palette both go through it,
- * so an entry cannot behave one way when clicked and another when searched.
- *
- * `onNavigate` is still passed, because the palette moves the router *without a
- * link*: Enter on a highlighted entry is a navigation nobody clicked, and it has
- * to be handed the same de-localized destination a `<Link>` would build. See
- * `#/lib/navigation`.
- *
- * ## `nav` is a projection, not the plugin registry
- *
- * `src/vitnode.config.ts` is server-side and carries message loaders, which a
- * browser bundle has no business holding. So the sidebar is built from
- * `#/lib/admin-nav`, which reads the generated browser-safe projection: ids,
- * hrefs, permissions, icons and content type definitions, and nothing that
- * renders a screen. The screens have a projection of their own - see
- * `#/lib/content-registry`, which the content route imports so that a plugin's
- * editor fields and form layouts land in that route's chunk rather than in the
- * shell's.
- *
- * It carries the message namespaces with it, because a plugin group's headings
- * live under that plugin's own id and the shell would otherwise render them as
- * dotted identifiers. `_admin`'s loader warms the same list.
- *
- * No navigation is derived from a plugin's route tree, in either direction: the
- * navigation model is complete regardless of which screen a click lands on, and
- * a nav entry is a product decision rather than a consequence of the route tree.
- */
-const searchUsers: AdminUserSearch = async search =>
-  await adminUserSearchFn({ data: { search } });
+import { adminNav } from "@/admin-nav.gen";
 
 export const AdminShell = ({ children }: { children: React.ReactNode }) => {
   const navigate = useAppNavigate();
@@ -64,7 +14,6 @@ export const AdminShell = ({ children }: { children: React.ReactNode }) => {
       onNavigate={href => {
         void navigate(href);
       }}
-      searchUsers={searchUsers}
     >
       {children}
     </AdminShellContent>

package/copy-of-vitnode-app/root/src/components/main-footer.tsx

@@ -0,0 +1,44 @@
+import {
+  VITNODE_DOCS_URL,
+  VITNODE_SPONSOR_URL,
+  VITNODE_WEBSITE_URL,
+} from "@vitnode/core/lib/docs-links";
+import { Heart } from "lucide-react";
+
+export const MainFooter = () => (
+  <footer className="border-t">
+    <div className="text-muted-foreground container mx-auto flex flex-col items-center justify-between gap-3 px-4 py-6 text-sm sm:flex-row">
+      <p>
+        Powered by{" "}
+        <a
+          className="text-foreground font-medium underline-offset-4 hover:underline"
+          href={VITNODE_WEBSITE_URL}
+          rel="noopener noreferrer"
+          target="_blank"
+        >
+          VitNode
+        </a>
+      </p>
+
+      <nav aria-label="VitNode" className="flex items-center gap-5">
+        <a
+          className="hover:text-foreground transition-colors"
+          href={VITNODE_DOCS_URL}
+          rel="noopener noreferrer"
+          target="_blank"
+        >
+          Docs
+        </a>
+        <a
+          className="hover:text-foreground flex items-center gap-1.5 transition-colors"
+          href={VITNODE_SPONSOR_URL}
+          rel="noopener noreferrer"
+          target="_blank"
+        >
+          <Heart className="size-3.5" />
+          Sponsor
+        </a>
+      </nav>
+    </div>
+  </footer>
+);

package/copy-of-vitnode-app/root/src/components/main-header.tsx

@@ -1,33 +1,4 @@
 import { MainHeader as MainHeaderContent } from "@vitnode/core/tanstack/layout";
 
-/**
- * The site header, as the main shell's slot for it.
- *
- * One line of application. The bar, the nav, the language and theme switchers,
- * the user area and both cache entries they read are
- * `@vitnode/core/tanstack/layout`'s `MainHeader`.
- *
- * **Your mark goes here.** Left alone the header renders VitNode's own, which is
- * the right default and the wrong answer for a real site. Pass your own:
- *
- *     <MainHeaderContent logo={<YourLogo />} />
- *
- * This file exists so that choosing a mark is a sentence a site says out loud
- * rather than something it inherits without noticing.
- *
- * No `LinkComponent`. Every header destination is a route in this application's
- * own tree, so the header's own default - `RouterLink`, the router's `Link` in
- * the shape the shared views ask for - is the right one, and the prop stays
- * available for a host that needs to answer differently.
- *
- * ## What the shell owes it
- *
- * Two warm cache entries, both ensured by `_main`'s loader:
- *
- *     headerIntlQueryOptions  ->  a `useSuspenseQuery`, so this is required
- *     prefetchSession         ->  the first paint shows the visitor, not a gap
- *
- * See the loader in `routes/_main.tsx`, which states why one is `ensure` and the
- * other `prefetch`.
- */
+
 export const MainHeader = () => <MainHeaderContent />;

package/copy-of-vitnode-app/root/src/lib/i18n.ts

@@ -0,0 +1,37 @@
+/**
+ * The one bootstrap adapter this application still owns.
+ *
+ * Auth, the AdminCP session and the AdminCP user search all reach the API
+ * through `@vitnode/core`'s own default transports now, so none of them needs a
+ * module here. Messages cannot work that way, for two reasons that only hold
+ * in app source:
+ *
+ * - `loadIntlMessages` reads *this* application's locale barrels, which are the
+ *   app's own files plus whichever packages it installed. A package cannot know
+ *   them.
+ * - `createServerFn` is extracted by the TanStack Start compiler, and the
+ *   compiler only runs over the application's source. `@vitnode/core` ships
+ *   precompiled, so a server function declared there would never have its
+ *   handler extracted and would resolve to `undefined` at runtime.
+ *
+ * `configureIntl` is where the two meet: the app hands core the fetch and its
+ * configured languages, and everything else in the package reads them back
+ * through `getIntlRuntime()`.
+ */
+import { createServerFn } from "@tanstack/react-start";
+import { configureIntl, validateIntlInput } from "@vitnode/core/tanstack/i18n";
+import { IntlProvider } from "use-intl";
+
+import { loadIntlMessages } from "@/server/messages.server";
+import { vitNodeConfig } from "@/vitnode.config";
+
+export const getIntlMessages = createServerFn()
+  .validator(validateIntlInput)
+  .handler(async ({ data }) => await loadIntlMessages(data));
+
+export const { localeRouting } = configureIntl({
+  fetchMessages: async input => await getIntlMessages({ data: input }),
+
+  hostIntlProvider: IntlProvider,
+  i18n: vitNodeConfig.i18n,
+});

package/copy-of-vitnode-app/root/src/locales/app.ts

@@ -1,28 +1,4 @@
 import type { AppMessagesMap } from "@vitnode/core/lib/i18n/types";
 
-/**
- * Translations this app owns, on top of whatever the packages ship.
- *
- * Empty, and usually stays that way. Every VitNode package ships its own
- * translations and `locales/packages.ts` is what registers them - carrying a
- * second copy of a string a package already owns is how one product comes to
- * spell the same settings tab two different ways.
- *
- * What belongs here is a string this app *changes*. Add a locale, then the key
- * you are rewording:
- *
- *     export const appMessages: AppMessagesMap = {
- *       en: {
- *         '@vitnode/core': async () => await import('./en.json'),
- *       },
- *     }
- *
- * Deep-merged last, so a file here only needs the keys it actually changes:
- * everything it leaves out falls back to the package's, and then to the default
- * locale, key by key.
- *
- * Server-side only, and kept out of `src/i18n.ts` on purpose: these are
- * functions, and `src/i18n.ts` is spread into the shell config, which crosses to
- * the browser and has to stay serializable.
- */
+
 export const appMessages: AppMessagesMap = {};

package/copy-of-vitnode-app/root/src/locales/packages.ts

@@ -2,40 +2,7 @@ import type { LocaleMessagesMap } from "@vitnode/core/lib/i18n/types";
 
 import { CONFIG_PLUGIN as CORE } from "@vitnode/core/config";
 
-/**
- * Where this app reads each installed package's translations from.
- *
- * Every VitNode package ships a locale barrel - `@vitnode/core/locales/index` -
- * that loads its own files with a runtime
- * `import("./en.json", { with: { type: "json" } })`. Under Node that is exactly
- * right, and it is how an API app reads them.
- *
- * It cannot work here, and the reason is the import attribute rather than
- * anything about VitNode. Vite and Nitro inline `@vitnode/core`'s build output
- * into this app's server chunks - `ssr.external` applies to the SSR pass, not to
- * Nitro's own bundling - but Rollup will not follow a dynamic import that
- * carries `with: { type: "json" }`, so it neither emits the JSON nor rewrites
- * the specifier. What ships is a relative import pointing next to a chunk that
- * the JSON was never copied to, and every string on the page renders as its own
- * key.
- *
- * So the loaders are declared here instead, with static specifiers a bundler can
- * follow. Each resolves through the package's `./locales/*.json` export to the
- * real file and lands in the build as a chunk fetched on demand, which is the
- * same laziness the barrels wanted.
- *
- * **Add a line here for every plugin you install.** A plugin registered in
- * `vitnode.config.ts` with no entry in this map renders its own strings as keys:
- *
- *     import { CONFIG_PLUGIN as BLOG } from '@acme/blog/const'
- *
- *     [BLOG.pluginId]: {
- *       en: async () => await import('@acme/blog/locales/en.json'),
- *     },
- *
- * This is the app's *only* copy of that list - `vitnode.config.ts` and
- * `server/messages.server.ts` both read it from here.
- */
+
 export const packageMessages: Record<string, LocaleMessagesMap> = {
   [CORE.pluginId]: {
     en: async () => await import("@vitnode/core/locales/en.json"),