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

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

@@ -1,37 +0,0 @@
-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),
-});
-
-export const adminUserSearchFn = createServerFn({ method: "POST" })
-  .validator(adminUserSearchInput)
-  .handler(async ({ data }) => await readAdminUserSearchOnApi(data.search));

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

@@ -1,66 +0,0 @@
-import { createServerFn } from "@tanstack/react-start";
-import {
-  changePasswordInputSchema,
-  passwordResetRequestInputSchema,
-  setAuthTransport,
-  signInInputSchema,
-  signOutInputSchema,
-  signUpInputSchema,
-  ssoCallbackInputSchema,
-  ssoStartInputSchema,
-} from "@vitnode/core/tanstack/auth";
-import {
-  changePasswordFromResetOnApi,
-  completeSsoOnApi,
-  readSessionOnApi,
-  requestPasswordResetOnApi,
-  signInOnApi,
-  signOutOnApi,
-  signUpOnApi,
-  startSsoOnApi,
-} from "@vitnode/core/tanstack/auth/server";
-
-export const readSessionFn = createServerFn().handler(
-  async () => await readSessionOnApi(),
-);
-
-export const signInFn = createServerFn({ method: "POST" })
-  .validator(signInInputSchema)
-  .handler(async ({ data }) => await signInOnApi(data));
-
-export const signOutFn = createServerFn({ method: "POST" })
-  .validator(signOutInputSchema)
-  .handler(async ({ data }) => await signOutOnApi(data));
-
-export const startSsoFn = createServerFn({ method: "POST" })
-  .validator(ssoStartInputSchema)
-  .handler(async ({ data }) => await startSsoOnApi(data));
-
-export const completeSsoFn = createServerFn({ method: "POST" })
-  .validator(ssoCallbackInputSchema)
-  .handler(async ({ data }) => await completeSsoOnApi(data));
-
-export const signUpFn = createServerFn({ method: "POST" })
-  .validator(signUpInputSchema)
-  .handler(async ({ data }) => await signUpOnApi(data));
-
-export const requestPasswordResetFn = createServerFn({ method: "POST" })
-  .validator(passwordResetRequestInputSchema)
-  .handler(async ({ data }) => await requestPasswordResetOnApi(data));
-
-export const changePasswordFromResetFn = createServerFn({ method: "POST" })
-  .validator(changePasswordInputSchema)
-  .handler(async ({ data }) => await changePasswordFromResetOnApi(data));
-
-setAuthTransport({
-  changePasswordFromReset: async input =>
-    await changePasswordFromResetFn({ data: input }),
-  completeSso: async input => await completeSsoFn({ data: input }),
-  readSession: async () => await readSessionFn(),
-  requestPasswordReset: async input =>
-    await requestPasswordResetFn({ data: input }),
-  signIn: async input => await signInFn({ data: input }),
-  signOut: async input => await signOutFn({ data: input }),
-  signUp: async input => await signUpFn({ data: input }),
-  startSso: async input => await startSsoFn({ data: input }),
-});

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

@@ -1,51 +0,0 @@
-import {
-  buildContentFrontendRegistry,
-  setContentFrontendRegistry,
-} from "@vitnode/core/content";
-
-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`
- *
- * That config is server-side on purpose (`vitnode.shell.config.ts` explains the
- * split): it carries message loaders and API wiring, which a browser bundle has
- * no business holding. The generated projection is the browser-safe half - the
- * definitions, the icons and the override components - so the AdminCP gets the
- * content screens without the server config. 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/document-headers.ts

@@ -1,128 +0,0 @@
-/**
- * What a VitNode document response may say about being stored.
- *
- * `private, no-store`, and it is not a precaution - it is a description of what
- * is in the body. Every page this application renders streams a dehydrated Query
- * cache into its HTML, and that cache always holds `["vitnode","session"]`: the
- * visitor's own name, avatar and `isAdmin` flag. Inside `/admin` it also holds
- * `["vitnode","admin-session"]`, which is that administrator's entire permission
- * set. `tanstack/auth/session-query` and `tanstack/admin/session-query` both say
- * so in their own words - "that document is personalised and must not be served
- * from a shared cache" - and until now nothing on the response said it back.
- *
- * Nothing caches these documents today. That is a property of the current
- * deployment, not of the application: the moment a CDN, a reverse proxy or a
- * `Cache-Control`-respecting edge sits in front of the Node server, an absent
- * directive is an invitation to store one visitor's HTML and serve it to the
- * next. Stage 15 is when that becomes likely, so the header belongs here now.
- *
- * ## It is an invariant, not a default
- *
- * This started as a fallback for documents that said nothing, and that was
- * wrong. A default is something a route may override, and at this architecture
- * level there is no override a route could correctly choose: the dehydrated
- * cache is written into the stream by `setupRouterSsrQueryIntegration` for
- * *every* document, so a route opting into `public, max-age=60` would be
- * publishing whichever visitor rendered first to everyone who asked next. The
- * route cannot know that, because the private payload is not something the route
- * put there.
- *
- * So the directive is forced rather than filled in, and a route that sets its
- * own is overwritten rather than obeyed. That is the whole difference between
- * this being a hardening measure and it being a security invariant.
- *
- * Public document caching is not forbidden forever - it is forbidden *while the
- * session is dehydrated into the document*. Introducing it later is a separate,
- * explicit piece of architecture in which the private state is kept out of the
- * shared body (a public shell fetching its session client-side, say), and the
- * invariant here would move with it rather than being quietly relaxed by a route
- * that wanted a faster page.
- *
- * `private` bars a shared cache. `no-store` bars every cache, including the
- * browser's own disk cache - which is the half that matters on a shared machine,
- * where the previous person's permission set should not be recoverable from
- * `chrome://cache` after they sign out. The pair is the standard spelling for
- * "this body belongs to exactly one person, once".
- *
- * The known cost is the back/forward cache. `no-store` used to make a page
- * outright ineligible for bfcache in Chromium; current versions keep such pages
- * eligible but evict them when cookies change - which for this app means a
- * sign-in or sign-out invalidates a back-navigation that would otherwise have
- * restored a page rendered for the previous session. That is the correct trade
- * and the outcome anybody would want, but it is a real difference and it is
- * worth a look during a manual pass rather than a surprise later.
- */
-export const DOCUMENT_CACHE_CONTROL = "private, no-store";
-
-/**
- * Whether this response is one of the documents the rule above describes.
- *
- * One question, and it is what keeps the API out of it. `/api/*` is served by
- * the Hono bridge through this same middleware, and a bare `GET` from it carries
- * no `Cache-Control` of its own - so a rule that applied to every response would
- * quietly forbid clients from caching the API. An HTML content-type is the
- * honest way to ask "is this a page", it needs no path list to be kept in step
- * with the router, and it cannot be wrong about a response that has already been
- * produced.
- *
- * It deliberately does *not* ask whether a directive is already present. That
- * used to be the second half of this predicate, and it is exactly the exemption
- * the invariant above cannot afford - see {@link applyDocumentCacheControl}.
- *
- * A redirect is deliberately not matched here - it has no content type - and is
- * handled by {@link applyRedirectCacheControl} instead, which wants a narrower
- * rule.
- */
-const isRenderedDocument = (headers: Headers): boolean =>
-  (headers.get("content-type") ?? "").toLowerCase().startsWith("text/html");
-
-/**
- * Says what a rendered document is, on the response about to be sent.
- *
- * `set` rather than a conditional fill, and that is the fix: whatever the
- * response was carrying is replaced. A route cannot opt out, because a route is
- * not in a position to know what is in the body it is opting out for.
- *
- * Only `text/html` is touched. Everything else the middleware sees - the API,
- * assets, client chunks, a `204` with no content type at all - keeps whatever it
- * had, including nothing.
- *
- * Mutates rather than returning a new `Response`, because the middleware already
- * holds the one Start produced and rebuilding it would mean copying a stream.
- * The same reason `set-cookie` is appended in place a few lines away.
- */
-export const applyDocumentCacheControl = (response: Response): void => {
-  if (!isRenderedDocument(response.headers)) return;
-
-  response.headers.set("cache-control", DOCUMENT_CACHE_CONTROL);
-};
-
-/**
- * The same for a locale redirect, but only when it is carrying a cookie.
- *
- * A `308` from `/en/discover` to `/discover` is a fact about URLs, identical for
- * every visitor, and permanently cacheable - which is most of the point of
- * answering with one. So it keeps that property by default.
- *
- * The exception is the redirect that also writes the locale cookie, which is
- * what `/pl/admin` produces: a stored copy of that would hand the next visitor
- * through the same shared cache a `Set-Cookie` chosen by somebody else, and
- * quietly switch their language. Shared caches are generally expected to refuse
- * a `Set-Cookie` response, but "generally expected" is not a property this
- * application can assert about somebody else's proxy, and one visitor's cookie
- * reaching another's browser is not the kind of thing to leave to convention.
- *
- * So the cookie-carrying case is forced, for the same reason the document is: a
- * `public` directive already on such a redirect is overwritten rather than
- * respected, because the thing that makes it unsafe to share is the `Set-Cookie`
- * beside it and not whatever the directive claims.
- *
- * The cookie-less case keeps its existing semantics untouched, directive and
- * all. It carries no private state, so there is nothing here to protect and
- * nothing to override.
- */
-export const applyRedirectCacheControl = (response: Response): void => {
-  if (!response.headers.has("set-cookie")) return;
-
-  response.headers.set("cache-control", DOCUMENT_CACHE_CONTROL);
-};

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

@@ -1,75 +0,0 @@
-import { createServerFn } from "@tanstack/react-start";
-import { configureIntl, validateIntlInput } from "@vitnode/core/tanstack/i18n";
-import { IntlProvider } from "use-intl";
-
-import { i18n } from "#/i18n";
-import { loadIntlMessages } from "#/server/messages.server";
-
-/**
- * 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 the two framework entry points, `src/router.tsx` and
- * `src/start.ts`, both import from here, and `src/tests/intl-runtime.test.ts`
- * fails if either stops doing so.
- *
- * 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,
-});
-
-/**
- * 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

@@ -1,20 +0,0 @@
-import type { i18n } from "#/i18n";
-
-import { localeRouting } from "#/lib/i18n/runtime";
-
-/**
- * A language this app serves, as a type. `"en" | "pl"`, 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 i18n.locales)[number]["code"];
-
-export { defaultLocale, localeRouting } from "#/lib/i18n/runtime";
-
-/** Narrows a string - a URL segment, a cookie, a `<select>` value - to a locale. */
-export const isLocale = (value: null | string | undefined): value is Locale =>
-  localeRouting.isSupportedLocale(value);

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

@@ -1,24 +0,0 @@
-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

@@ -1,19 +0,0 @@
-import { createRouteHead } from "@vitnode/core/tanstack/metadata";
-
-import { vitNodeShellConfig } from "#/vitnode.shell.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(vitNodeShellConfig.metadata);

package/copy-of-vitnode-app/root/src/vitnode.shell.config.ts

@@ -1,35 +0,0 @@
-import type { VitNodeConfig } from "@vitnode/core/vitnode.config";
-
-import { i18n } from "./i18n";
-
-/**
- * The VitNode config the browser is allowed to see.
- *
- * Everything in `VitNodeConfig` except `plugins`, and that omission is the whole
- * point. The plugin registry carries each plugin's translations as `import()`s
- * of JSON inside its `dist`, and eventually its AdminCP components - neither of
- * which a browser bundle should hold. In Next.js the boundary is drawn for you:
- * `vitnode.config.ts` is only ever read by Server Components, so none of it
- * reaches the client. TanStack Start has no such boundary - anything the root
- * route imports is in the browser bundle - so the split is made here instead, by
- * hand.
- *
- * `vitnode.config.ts` spreads this into `buildConfig` with the plugins added, so
- * there is one source for the metadata, the theme and the locales rather than
- * two that agree until they don't.
- *
- * Everything here is plain, serializable data. That is a rule, not a
- * coincidence: this module is imported by the document shell, which renders on
- * both sides of hydration.
- */
-export const vitNodeShellConfig = {
-  debug: false,
-  i18n,
-  metadata: {
-    shortTitle: "VitNode",
-    title: "VitNode",
-  },
-  theme: {
-    defaultTheme: "system",
-  },
-} satisfies Omit<VitNodeConfig, "plugins">;