create-vitnode-app 2.0.0-canary.3 → 2.0.0-canary.5

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

@@ -12,25 +12,7 @@ export const POSTGRES_URL =
 
 export const vitNodeApiConfig = buildApiConfig({
   plugins: [],
-  /**
-   * The languages this installation serves.
-   *
-   * The API half of a split deployment. `apps/web/src/vitnode.config.ts`
-   * declares the same list, and the two are one declaration in two places by
-   * necessity rather than by design: they are separate packages, so neither can
-   * import the other's. Nothing walks the filesystem looking for the web app's
-   * config either - a bootstrap that guessed at a sibling application is exactly
-   * what that replaced, and it guessed wrong the moment the two were not laid
-   * out the way it expected.
-   *
-   * They have to agree, and this is the copy that matters most: this app owns
-   * the schema, so `vitnode db:prepare` seeds `core_languages` from *this* list.
-   * A language that is here and not in the web app's renders nowhere; one that
-   * is in the web app's and not here has no row in the database.
-   *
-   * Packages ship their own translations, so a new locale needs no `messages`
-   * entry - anything untranslated falls back to `defaultLocale` key by key.
-   */
+  
   i18n: {
     defaultLocale: "en",
     locales: [{ code: "en", name: "English" }],

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

@@ -2,28 +2,7 @@ import { createFileRoute } from '@tanstack/react-router'
 
 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/$')({
   server: {
     handlers: ({ createHandlers }) =>

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/vitnode.api.config.ts

@@ -13,15 +13,7 @@ export const vitNodeApiConfig = buildApiConfig({
     shortTitle: "VitNode",
   },
   plugins: [],
-  /**
-   * The site's own locale declaration, because this app is both: `vitnode.config.ts`
-   * is the one statement of which languages exist, and both configs read it.
-   *
-   * It is also what `vitnode db:prepare` seeds `core_languages` from - this app
-   * owns the schema - so adding a language there and re-running `dev` inserts
-   * its row. Leave it out and the seed falls back to `en` alone, whatever the
-   * site serves.
-   */
+  
   i18n: vitNodeConfig.i18n,
   dbProvider: drizzle({
     connection: POSTGRES_URL,

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

@@ -12,7 +12,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 +26,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

@@ -17,13 +17,13 @@
       "dependsOn": ["^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

@@ -7,50 +7,7 @@ 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 } });
 

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/admin-nav.ts

@@ -2,42 +2,5 @@ import { adminNavBundle } from "@vitnode/core/tanstack/admin";
 
 import { pluginAdminNav } from "#/admin-nav.gen";
 
-/**
- * This installation's AdminCP navigation - core's own, plus whatever the plugins
- * it configured contribute.
- *
- * Two lines, and both of them are host-only work by necessity. Which plugins are
- * installed is a property of this application, and `src/admin-nav.gen.ts` is
- * where the build writes the answer: one literal import per configured plugin
- * that exports an `admin/nav` module. Every *rule* about what a sidebar contains
- * - which entries a content type earns, how a hand-declared entry is titled,
- * which permission hides one, which message namespaces the result needs - is
- * `@vitnode/core`'s, in `adminNavBundle`. Nothing about navigation is decided
- * here.
- *
- * ## Why it is not read from `vitnode.config.ts`
- *
- * The config does carry each plugin's registration, and a Next.js host walks it
- * in its render pass. Reading it here would make every configured plugin's
- * editing screens reachable from the module the document shell imports, which is
- * the one graph that is never lazy. The generated projection carries exactly
- * what a sidebar needs instead - ids, hrefs, permissions, icons and content type
- * definitions, all plain data - and the Content Engine's UI arrives separately,
- * when a content screen actually renders, through `src/lib/content-registry.ts`.
- *
- * ## Module scope, and why that matters twice
- *
- * Evaluated once per bundle rather than per render. `AdminShellContent` memoises
- * its namespace list on this object's identity, and `_admin`'s loader warms the
- * messages from the same `namespaces` array the shell then reads - so a stable
- * value here is what makes those one cache entry rather than two.
- *
- * ## Content entries were never rewritten, and that is the point
- *
- * A content type's entry is `/admin/content/…`, and it said exactly that
- * through every change in which framework rendered those screens. Only *how a
- * click travels* ever changed, and nothing here was edited for it. Routes and
- * navigation stay separate concepts: nothing derives a nav entry from a route
- * file, and nothing makes one conditional on a route existing.
- */
+
 export const adminNav = adminNavBundle({ plugins: pluginAdminNav });

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

@@ -2,32 +2,7 @@ import { createServerFn } from "@tanstack/react-start";
 import { readAdminUserSearchOnApi } from "@vitnode/core/tanstack/admin/server";
 import { z } from "zod";
 
-/**
- * The AdminCP command palette's user lookup, as this app's server function.
- *
- * One handler, one line, exactly like `lib/auth.ts` - and here for the same
- * reason. `createServerFn` needs the module it sits in to be transformed by the
- * Start compiler on both sides of the render, and `@vitnode/core` reaches the
- * server un-compiled (see the note in `lib/auth.ts`), so the declaration lives
- * in the host and the behaviour lives in the package.
- *
- * ## Why it has a validator
- *
- * A server function is a public same-origin endpoint: its input is whatever a
- * caller posts, not whatever the dialog typed. This value reaches an API query
- * string, so it is parsed rather than trusted - trimmed, length-bounded, and a
- * string at all.
- *
- * The bound is not a security control; the API authorizes the read from the
- * admin cookie and pages it itself. It is a cheap refusal of the requests that
- * could only ever be abuse - a megabyte of "search term" that the API would
- * otherwise have to hand to Postgres.
- *
- * `POST` puts it behind `createCsrfMiddleware` in `src/start.ts`, which matters
- * more here than it looks: this reads other people's names and email addresses,
- * and a `GET` would be reachable from another origin's page with the
- * administrator's cookies attached.
- */
+
 const adminUserSearchInput = z.object({
   search: z.string().trim().min(1).max(128),
 });

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

@@ -5,48 +5,7 @@ import {
 
 import { pluginContentTypes } from "#/content-registry.gen";
 
-/**
- * This installation's Content Engine registry - every content type its
- * configured plugins register, with their editing screens attached.
- *
- * Two lines, and both of them are host-only work by necessity. Which plugins are
- * installed is a property of this application, and `src/content-registry.gen.ts`
- * is where the build writes the answer: one literal import per configured plugin
- * that exports an `admin/content` module. Every *rule* about what a registration
- * is - which paths are legal, which two of them collide, how they are ordered,
- * how one is found by id or by `admin.path` - is `@vitnode/core`'s, in
- * `buildContentFrontendRegistry`. Nothing about the Content Engine is decided
- * here.
- *
- * ## Why it is not read from `vitnode.config.ts`
- *
- * The config does carry each plugin's registration, and a Next.js host reads it
- * from there. What it cannot give is *when*: it is imported by the document
- * shell, so anything reachable from it is reachable eagerly. This module is
- * loaded behind a dynamic `import()` in `src/router.tsx` instead, so the
- * definitions, the icons and the override components arrive with the content
- * route - the same arrangement `src/lib/admin-nav.ts` uses for the sidebar, one
- * layer deeper.
- *
- * ## Registration, and where it belongs in the import graph
- *
- * `setContentFrontendRegistry` fills a module-scope slot in `@vitnode/core`, so
- * the package's own content code finds the registry without being handed it as
- * a prop - the same shape as `setAdminTransport`. Module scope means *per
- * bundle*: the browser has one instance and the server has one, and each
- * registers its own.
- *
- * This module is reached through a `() => import(...)` that `/admin/content`'s
- * loader awaits, never through a static import, and that is deliberate.
- * Registration only has to happen before a content screen runs, and deferring it
- * to the route is what lets Rollup put this whole graph - every plugin's field
- * components, table cells and form layouts, plus `zod` and the Content Engine
- * itself - in that route's chunk instead of in the bundle every page of the site
- * loads first. `router.tsx` holds the thunk because that is where the route tree
- * is composed; what it does *not* hold is the value. A plugin's own heavier
- * parts stay lazier still: `@vitnode/blog` draws a `React.lazy` boundary around
- * its Tiptap editor, so even opening the article list does not fetch it.
- */
+
 export const contentRegistry = buildContentFrontendRegistry(pluginContentTypes);
 
 setContentFrontendRegistry(contentRegistry);

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

@@ -5,71 +5,22 @@ import { IntlProvider } from "use-intl";
 import { loadIntlMessages } from "#/server/messages.server";
 import { vitNodeConfig } from "#/vitnode.config";
 
-/**
- * One language's messages for one set of namespaces, fetched on the server.
- *
- * The one piece of the i18n runtime that cannot live in `@vitnode/core`, and the
- * reason is the compiler rather than the code. A server function has to be
- * transformed by the Start plugin in *both* bundles; the package is externalised
- * from this app's SSR pass, so its modules reach the server un-compiled and a
- * `createServerFn` declared there resolves to `undefined` during SSR with no
- * error. See `packages/vitnode/src/tanstack/boundary.test.ts`.
- *
- * So the wrapper is here and the body is not: `validateIntlInput` is core's, and
- * `loadIntlMessages` delegates to core's loading engine. Start strips the
- * handler - and `#/server/messages.server` with it - out of the client build.
- */
+
 export const getIntlMessages = createServerFn()
   .validator(validateIntlInput)
   .handler(async ({ data }) => await loadIntlMessages(data));
 
-/**
- * This app's languages, handed to the package once.
- *
- * Everything in `@vitnode/core/tanstack/i18n` reads what this registers, so a
- * route file imports `RouteMessages` and `intlQueryOptions` straight from the
- * package. What must not happen is a route running before this module has been
- * evaluated - so `src/router.tsx`, which owns the route tree, imports from
- * here. The request pipeline needs no such guarantee: `createVitNodeStart`
- * derives its own locale routing from the config it is handed.
- *
- * The registration is at module scope but reads `getIntlMessages` above only by
- * reference, so the order within this file does not matter: the validator and
- * the fetcher are both called per request, long after it has finished
- * evaluating.
- */
+
 export const {
   defaultLocale,
   isLocale: isSupportedLocale,
   localeRouting,
 } = configureIntl({
   fetchMessages: async input => await getIntlMessages({ data: input }),
-  /**
-   * This app's own `use-intl`, handed over so `RouteMessages` can provide it.
-   *
-   * `@vitnode/core` is external to this app's SSR pass (`vite.config.ts`), so
-   * under `vite dev` Node loads the package and Vite loads this app, and the two
-   * resolve `use-intl` to two different files - two `createContext` calls, two
-   * React contexts. Everything the package renders reads its own; anything this
-   * app renders with its own `useTranslations` - `routes/_main/index.tsx` does -
-   * reads this one, and nothing inside the package can import it.
-   *
-   * So it is registered rather than imported, and `RouteMessages` mounts it
-   * outermost. A production build resolves `use-intl` once and the providers
-   * collapse into one, which is why leaving this out is a dev-only failure: the
-   * route's server render throws "No intl context found", React quietly falls
-   * back to client rendering, and the page still appears.
-   */
+  
   hostIntlProvider: IntlProvider,
   i18n: vitNodeConfig.i18n,
 });
 
-/**
- * The router's half of locale routing, bound to this app's languages.
- *
- * Re-exported from here rather than imported straight from the package by
- * `src/router.tsx`: it is the router entry's only i18n import, and routing it
- * through this module is what makes `configureIntl` above run before the router
- * - and therefore before any route, loader or component - exists.
- */
+
 export { createLocaleRewrite } from "@vitnode/core/tanstack/i18n";

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

@@ -2,15 +2,7 @@ import type { vitNodeConfig } from "#/vitnode.config";
 
 import { localeRouting } from "#/lib/i18n/runtime";
 
-/**
- * A language this app serves, as a type. `"en"`, or `"en" | "de"` once a second
- * one is declared - derived from the config rather than written twice.
- *
- * The one i18n thing this app still owns, and it has to: `@vitnode/core` is
- * installed by apps with different language lists, so it types a locale as
- * `string` and takes this union as a type argument where the value originates
- * (`useLocale<Locale>()`, `resolveLocale<Locale>()`).
- */
+
 export type Locale = (typeof vitNodeConfig.i18n.locales)[number]["code"];
 
 export { defaultLocale, localeRouting } from "#/lib/i18n/runtime";

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

@@ -2,23 +2,7 @@ import { createAuthNavigation } from "@vitnode/core/tanstack/auth";
 
 import { localeRouting } from "#/lib/i18n/shared";
 
-/**
- * Going somewhere in this application from code, bound to this app's languages.
- *
- * One line of application, and everything else is
- * `@vitnode/core/tanstack/auth`: the two questions a user-supplied target has to
- * answer (may we send a browser there, and what does the router want to be
- * handed), the reason a redirect carries `to` rather than `href`, and the fact
- * that the same decision is made on a server and in a browser.
- *
- * What is left here is the only thing a package cannot answer - which languages
- * this installation serves, which is what decides whether `/pl/discover` is a
- * Polish page or a route called `pl`.
- *
- * `@vitnode/core/tanstack/routes` builds its own from the same factory, handed
- * the same `localeRouting`, so core's auth screens and this app's AdminCP command
- * palette navigate by one rule rather than two.
- */
+
 export const { internalDestination, useAppNavigate } = createAuthNavigation({
   localeRouting,
 });

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

@@ -2,18 +2,5 @@ import { createRouteHead } from "@vitnode/core/tanstack/metadata";
 
 import { vitNodeConfig } from "#/vitnode.config";
 
-/**
- * A route's `head`, bound to this app's name.
- *
- * Two lines of application, and everything else is
- * `@vitnode/core/tanstack/metadata`: the `"<page> - <site>"` title rule Next.js
- * applies through `title.template`, the decision that a robots directive is
- * stated rather than assumed, and the handling of a `loaderData` that is
- * `undefined` on a route's first pass.
- *
- * What is left here is the only thing a package cannot answer - this site's own
- * name, which is what every tab title ends with.
- *
- *     head: ({ loaderData }) => pageHead({ robots: 'index, follow', ...loaderData })
- */
+
 export const pageHead = createRouteHead(vitNodeConfig.metadata);

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/vitnode.config.ts` on purpose: these
- * are functions, and the shared config crosses to the browser and has to stay
- * serializable. `src/vitnode.server.config.ts` is what registers this map.
- */
+
 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.server.config.ts` reads it
- * from here.
- */
+
 export const packageMessages: Record<string, LocaleMessagesMap> = {
   [CORE.pluginId]: {
     en: async () => await import("@vitnode/core/locales/en.json"),