create-nextblock 0.16.1 → 0.16.3

package/templates/nextblock-template/app/cms/settings/seo/mappers.ts

@@ -1,93 +1,93 @@
-/**
- * The snake_case ↔ camelCase boundary for managed redirects.
- *
- * The database speaks `source_path` / `is_active`; the pure SEO engine in
- * `@nextblock-cms/utils/seo` speaks `sourcePath` / `isActive`. Exactly one place is
- * allowed to know both vocabularies, and this is it — every other module on this
- * screen sees one shape or the other and never has to guess which.
- *
- * These helpers are pure and live outside `actions.ts` deliberately: that file is
- * `'use server'`, where every export must be an async server action, so a synchronous
- * mapper cannot be exported from there. Keeping them here also means the client
- * components can use the identical mapping the actions use, which is what lets the
- * browser run the real `validateRedirectRule` against the real rule set before a
- * request is ever made.
- */
-
-import type { RedirectRule, RedirectStatusCode } from '@nextblock-cms/utils/seo';
-
-import { mapRedirectRow, type CmsRedirectRow } from '../../../../lib/seo/redirect-store';
-
-/**
- * A row of `public.cms_redirects` as this screen sees it.
- *
- * WHY IT IS AN ALIAS AND NOT A SECOND HAND-WRITTEN INTERFACE. The row shape was
- * already transcribed from migration 00000000000030's DDL in `lib/seo/redirect-store.ts`,
- * for the proxy's benefit, and for the same reason it had to be hand-written there:
- * `libs/db`'s generated `Database` type comes from `npm run db:types` against a live
- * project, that migration has not been applied yet, and so
- * `Database['public']['Tables']['cms_redirects']` does not compile today. Restating
- * the seven columns here would give the repo two hand-written descriptions of one
- * table that could drift apart in a rename; aliasing gives it one. When the migration
- * lands and the types are regenerated, there is a single interface to delete.
- */
-export type CmsRedirect = CmsRedirectRow;
-
-/**
- * What the add/edit form collects, in the engine's vocabulary.
- *
- * `statusCode` is `RedirectStatusCode` rather than `number` so a widened value cannot
- * reach the database and trip the table's CHECK constraint as an opaque Postgres
- * error; the server re-validates it with Zod regardless, because a type says nothing
- * about what actually arrived over the wire.
- */
-export interface RedirectInput {
-  destinationPath: string;
-  isActive: boolean;
-  sourcePath: string;
-  statusCode: RedirectStatusCode;
-}
-
-/**
- * Maps stored rows onto the engine's rule shape, dropping any row too malformed to
- * be a rule at all.
- *
- * Reuses `mapRedirectRow`, the proxy's mapper, so the admin screen's idea of the
- * current rule set is byte-for-byte the proxy's idea of it. That agreement is what
- * makes client-side validation trustworthy: a duplicate or a loop the admin screen
- * refuses is a duplicate or a loop the proxy would actually have hit.
- *
- * Unlike the proxy's query this one is given inactive rows too, and that is
- * intentional — `validateRedirectRule` counts a paused rule when checking for
- * duplicates and loops, so re-enabling one cannot introduce a conflict that
- * validation already waved through.
- */
-export function toRedirectRules(rows: CmsRedirect[]): RedirectRule[] {
-  const rules: RedirectRule[] = [];
-
-  for (const row of rows) {
-    const rule = mapRedirectRow(row);
-    if (rule !== null) {
-      rules.push(rule);
-    }
-  }
-
-  return rules;
-}
-
-/**
- * Maps one stored row onto the form's input shape, for the inline editor.
- *
- * Falls back to 301 for an out-of-range `status_code` for the same reason
- * `mapRedirectRow` does: the column is constrained to 301/302, so the fallback never
- * fires in practice, and defaulting to permanent keeps a rule the operator can see in
- * the list from silently becoming un-editable.
- */
-export function toRedirectInput(row: CmsRedirect): RedirectInput {
-  return {
-    destinationPath: row.destination_path,
-    isActive: row.is_active,
-    sourcePath: row.source_path,
-    statusCode: row.status_code === 302 ? 302 : 301,
-  };
-}
+/**
+ * The snake_case ↔ camelCase boundary for managed redirects.
+ *
+ * The database speaks `source_path` / `is_active`; the pure SEO engine in
+ * `@nextblock-cms/utils/seo` speaks `sourcePath` / `isActive`. Exactly one place is
+ * allowed to know both vocabularies, and this is it — every other module on this
+ * screen sees one shape or the other and never has to guess which.
+ *
+ * These helpers are pure and live outside `actions.ts` deliberately: that file is
+ * `'use server'`, where every export must be an async server action, so a synchronous
+ * mapper cannot be exported from there. Keeping them here also means the client
+ * components can use the identical mapping the actions use, which is what lets the
+ * browser run the real `validateRedirectRule` against the real rule set before a
+ * request is ever made.
+ */
+
+import type { RedirectRule, RedirectStatusCode } from '@nextblock-cms/utils/seo';
+
+import { mapRedirectRow, type CmsRedirectRow } from '../../../../lib/seo/redirect-store';
+
+/**
+ * A row of `public.cms_redirects` as this screen sees it.
+ *
+ * WHY IT IS AN ALIAS AND NOT A SECOND HAND-WRITTEN INTERFACE. The row shape was
+ * already transcribed from migration 00000000000030's DDL in `lib/seo/redirect-store.ts`,
+ * for the proxy's benefit, and for the same reason it had to be hand-written there:
+ * `libs/db`'s generated `Database` type comes from `npm run db:types` against a live
+ * project, that migration has not been applied yet, and so
+ * `Database['public']['Tables']['cms_redirects']` does not compile today. Restating
+ * the seven columns here would give the repo two hand-written descriptions of one
+ * table that could drift apart in a rename; aliasing gives it one. When the migration
+ * lands and the types are regenerated, there is a single interface to delete.
+ */
+export type CmsRedirect = CmsRedirectRow;
+
+/**
+ * What the add/edit form collects, in the engine's vocabulary.
+ *
+ * `statusCode` is `RedirectStatusCode` rather than `number` so a widened value cannot
+ * reach the database and trip the table's CHECK constraint as an opaque Postgres
+ * error; the server re-validates it with Zod regardless, because a type says nothing
+ * about what actually arrived over the wire.
+ */
+export interface RedirectInput {
+  destinationPath: string;
+  isActive: boolean;
+  sourcePath: string;
+  statusCode: RedirectStatusCode;
+}
+
+/**
+ * Maps stored rows onto the engine's rule shape, dropping any row too malformed to
+ * be a rule at all.
+ *
+ * Reuses `mapRedirectRow`, the proxy's mapper, so the admin screen's idea of the
+ * current rule set is byte-for-byte the proxy's idea of it. That agreement is what
+ * makes client-side validation trustworthy: a duplicate or a loop the admin screen
+ * refuses is a duplicate or a loop the proxy would actually have hit.
+ *
+ * Unlike the proxy's query this one is given inactive rows too, and that is
+ * intentional — `validateRedirectRule` counts a paused rule when checking for
+ * duplicates and loops, so re-enabling one cannot introduce a conflict that
+ * validation already waved through.
+ */
+export function toRedirectRules(rows: CmsRedirect[]): RedirectRule[] {
+  const rules: RedirectRule[] = [];
+
+  for (const row of rows) {
+    const rule = mapRedirectRow(row);
+    if (rule !== null) {
+      rules.push(rule);
+    }
+  }
+
+  return rules;
+}
+
+/**
+ * Maps one stored row onto the form's input shape, for the inline editor.
+ *
+ * Falls back to 301 for an out-of-range `status_code` for the same reason
+ * `mapRedirectRow` does: the column is constrained to 301/302, so the fallback never
+ * fires in practice, and defaulting to permanent keeps a rule the operator can see in
+ * the list from silently becoming un-editable.
+ */
+export function toRedirectInput(row: CmsRedirect): RedirectInput {
+  return {
+    destinationPath: row.destination_path,
+    isActive: row.is_active,
+    sourcePath: row.source_path,
+    statusCode: row.status_code === 302 ? 302 : 301,
+  };
+}

package/templates/nextblock-template/app/cms/settings/seo/page.tsx

@@ -1,46 +1,46 @@
-// app/cms/settings/seo/page.tsx
-import { hasResolvedSiteUrl, resolveSiteUrl } from '../../../../lib/site-url';
-import { getRedirects, getRobotsSettings } from './actions';
-import { requireAdminSupabaseClient } from './require-admin';
-import { SeoSettingsClient } from './SeoSettingsClient';
-
-/**
- * The SEO operations screen: which URLs moved, and what crawlers are allowed to do.
- *
- * ADMIN-only, and gated here as well as in every action and in RLS. The gate is
- * repeated rather than delegated because the three layers protect different things:
- * this one stops a WRITER from ever seeing the screen (a redirect list is a map of a
- * site's history, and the robots block is a map of what it is hiding), the actions
- * stop a hand-rolled request that never loaded the page, and RLS stops everything
- * else. `requireAdminSupabaseClient` throws, which is the right behaviour for a
- * Server Component: an unauthorised visitor gets the error boundary instead of a
- * half-rendered admin screen.
- *
- * The two reads run concurrently because they are independent — one hits
- * `cms_redirects`, the other one row of `site_settings` — and running them in series
- * would add a whole round trip to a screen that is already behind an auth check.
- */
-export default async function SeoSettingsPage() {
-  await requireAdminSupabaseClient();
-
-  const [redirects, robotsSettings] = await Promise.all([getRedirects(), getRobotsSettings()]);
-
-  // Resolved on the server, where the deployment's env actually lives, and handed to
-  // the preview as data. The client component must never try to work this out for
-  // itself: `NEXT_PUBLIC_URL` is inlined at build time and the Vercel fallbacks are
-  // server-only, so a browser-side guess would quietly show a different sitemap URL
-  // from the one crawlers are given.
-  const siteUrl = resolveSiteUrl();
-
-  return (
-    <div className="mx-auto max-w-5xl space-y-6">
-      <SeoSettingsClient
-        initialRedirects={redirects}
-        initialRobotsSettings={robotsSettings}
-        isSandbox={process.env.NEXT_PUBLIC_IS_SANDBOX === 'true'}
-        isSiteUrlConfigured={hasResolvedSiteUrl()}
-        sitemapUrl={`${siteUrl}/sitemap.xml`}
-      />
-    </div>
-  );
-}
+// app/cms/settings/seo/page.tsx
+import { hasResolvedSiteUrl, resolveSiteUrl } from '../../../../lib/site-url';
+import { getRedirects, getRobotsSettings } from './actions';
+import { requireAdminSupabaseClient } from './require-admin';
+import { SeoSettingsClient } from './SeoSettingsClient';
+
+/**
+ * The SEO operations screen: which URLs moved, and what crawlers are allowed to do.
+ *
+ * ADMIN-only, and gated here as well as in every action and in RLS. The gate is
+ * repeated rather than delegated because the three layers protect different things:
+ * this one stops a WRITER from ever seeing the screen (a redirect list is a map of a
+ * site's history, and the robots block is a map of what it is hiding), the actions
+ * stop a hand-rolled request that never loaded the page, and RLS stops everything
+ * else. `requireAdminSupabaseClient` throws, which is the right behaviour for a
+ * Server Component: an unauthorised visitor gets the error boundary instead of a
+ * half-rendered admin screen.
+ *
+ * The two reads run concurrently because they are independent — one hits
+ * `cms_redirects`, the other one row of `site_settings` — and running them in series
+ * would add a whole round trip to a screen that is already behind an auth check.
+ */
+export default async function SeoSettingsPage() {
+  await requireAdminSupabaseClient();
+
+  const [redirects, robotsSettings] = await Promise.all([getRedirects(), getRobotsSettings()]);
+
+  // Resolved on the server, where the deployment's env actually lives, and handed to
+  // the preview as data. The client component must never try to work this out for
+  // itself: `NEXT_PUBLIC_URL` is inlined at build time and the Vercel fallbacks are
+  // server-only, so a browser-side guess would quietly show a different sitemap URL
+  // from the one crawlers are given.
+  const siteUrl = resolveSiteUrl();
+
+  return (
+    <div className="mx-auto max-w-5xl space-y-6">
+      <SeoSettingsClient
+        initialRedirects={redirects}
+        initialRobotsSettings={robotsSettings}
+        isSandbox={process.env.NEXT_PUBLIC_IS_SANDBOX === 'true'}
+        isSiteUrlConfigured={hasResolvedSiteUrl()}
+        sitemapUrl={`${siteUrl}/sitemap.xml`}
+      />
+    </div>
+  );
+}

package/templates/nextblock-template/app/cms/settings/seo/require-admin.ts

@@ -1,47 +1,47 @@
-import { createClient } from '@nextblock-cms/db/server';
-
-/**
- * Admin gate shared by the SEO settings server actions and by the page itself.
- *
- * Lives outside `actions.ts` because that file is `'use server'`, where every export
- * must itself be a valid server action — a helper that returns a Supabase client
- * cannot be exported from there. Keeping one copy matters more than the file count:
- * this is the check standing between a WRITER and the redirect table, and a redirect
- * rule is an open-redirect surface. Anyone who can write one can point every visitor
- * of `/checkout` at a phishing clone of the site, with the real domain in the
- * referrer, without touching a single page or post. The same reasoning is why
- * migration 00000000000030 grants writes on `cms_redirects` to ADMIN only and leaves
- * WRITER out entirely — the RLS policy is the boundary, and this is the friendly
- * error that keeps an operator from meeting it as an unexplained empty list.
- *
- * It throws rather than returning a result because its two kinds of caller want
- * opposite things. A Server Component wants the throw: an unauthorised visitor gets
- * the error boundary instead of a half-rendered admin screen. A server action called
- * from a client component wants a message it can render, so those callers catch the
- * throw and return it as data — see `requireAdminOrMessage` in `actions.ts` and the
- * note on `SettingsActionResult` about Next replacing uncaught Server Action error
- * messages with a generic string in production.
- */
-export async function requireAdminSupabaseClient() {
-  const supabase = createClient();
-  const {
-    data: { user },
-    error: userError,
-  } = await supabase.auth.getUser();
-
-  if (userError || !user) {
-    throw new Error('You must be logged in to manage SEO settings.');
-  }
-
-  const { data: profile, error: profileError } = await supabase
-    .from('profiles')
-    .select('role')
-    .eq('id', user.id)
-    .single();
-
-  if (profileError || !profile || profile.role !== 'ADMIN') {
-    throw new Error('You do not have permission to manage SEO settings.');
-  }
-
-  return { supabase, userId: user.id };
-}
+import { createClient } from '@nextblock-cms/db/server';
+
+/**
+ * Admin gate shared by the SEO settings server actions and by the page itself.
+ *
+ * Lives outside `actions.ts` because that file is `'use server'`, where every export
+ * must itself be a valid server action — a helper that returns a Supabase client
+ * cannot be exported from there. Keeping one copy matters more than the file count:
+ * this is the check standing between a WRITER and the redirect table, and a redirect
+ * rule is an open-redirect surface. Anyone who can write one can point every visitor
+ * of `/checkout` at a phishing clone of the site, with the real domain in the
+ * referrer, without touching a single page or post. The same reasoning is why
+ * migration 00000000000030 grants writes on `cms_redirects` to ADMIN only and leaves
+ * WRITER out entirely — the RLS policy is the boundary, and this is the friendly
+ * error that keeps an operator from meeting it as an unexplained empty list.
+ *
+ * It throws rather than returning a result because its two kinds of caller want
+ * opposite things. A Server Component wants the throw: an unauthorised visitor gets
+ * the error boundary instead of a half-rendered admin screen. A server action called
+ * from a client component wants a message it can render, so those callers catch the
+ * throw and return it as data — see `requireAdminOrMessage` in `actions.ts` and the
+ * note on `SettingsActionResult` about Next replacing uncaught Server Action error
+ * messages with a generic string in production.
+ */
+export async function requireAdminSupabaseClient() {
+  const supabase = createClient();
+  const {
+    data: { user },
+    error: userError,
+  } = await supabase.auth.getUser();
+
+  if (userError || !user) {
+    throw new Error('You must be logged in to manage SEO settings.');
+  }
+
+  const { data: profile, error: profileError } = await supabase
+    .from('profiles')
+    .select('role')
+    .eq('id', user.id)
+    .single();
+
+  if (profileError || !profile || profile.role !== 'ADMIN') {
+    throw new Error('You do not have permission to manage SEO settings.');
+  }
+
+  return { supabase, userId: user.id };
+}

package/templates/nextblock-template/app/cms/settings/site-scripts/page.tsx

@@ -1,51 +1,51 @@
-// app/cms/settings/site-scripts/page.tsx
-import { Card, CardContent, CardDescription, CardHeader, CardTitle } from '@nextblock-cms/ui';
-
-import { getSiteScriptRevisions, getSiteScripts } from './actions';
-import SiteScriptManager from './components/SiteScriptManager';
-
-export default async function SiteScriptsSettingsPage() {
-  const [scripts, revisions] = await Promise.all([getSiteScripts(), getSiteScriptRevisions()]);
-
-  return (
-    <div className="mx-auto max-w-5xl space-y-6">
-      <Card>
-        <CardHeader>
-          <CardTitle>Site Scripts</CardTitle>
-          <CardDescription>
-            JavaScript that runs on every page of the public site — animation helpers, chat widgets,
-            third-party embeds. Each script is injected with the page&apos;s Content-Security-Policy
-            nonce, so it runs without weakening the site&apos;s security headers. Disabled scripts are
-            never sent to visitors. Every change is logged and can be rolled back from the history
-            below.
-          </CardDescription>
-        </CardHeader>
-        <CardContent>
-          <SiteScriptManager initialRevisions={revisions} initialScripts={scripts} />
-        </CardContent>
-      </Card>
-
-      <Card>
-        <CardHeader>
-          <CardTitle>Where else code can live</CardTitle>
-        </CardHeader>
-        <CardContent className="space-y-2 text-sm text-muted-foreground">
-          <p>
-            <strong className="text-foreground">One page only?</strong> A rich-text block accepts an
-            inline <code>&lt;style&gt;</code> and <code>&lt;script&gt;</code> directly, so
-            page-specific effects do not need to live here.
-          </p>
-          <p>
-            <strong className="text-foreground">Site-wide styling?</strong> Use Themes &amp; CSS for
-            palettes and global stylesheets.
-          </p>
-          <p>
-            <strong className="text-foreground">Marketing or analytics tags?</strong> Put those under
-            Google Analytics instead — scripts there only fire once a visitor accepts cookies, which
-            is what consent law requires. Scripts on this page run unconditionally.
-          </p>
-        </CardContent>
-      </Card>
-    </div>
-  );
-}
+// app/cms/settings/site-scripts/page.tsx
+import { Card, CardContent, CardDescription, CardHeader, CardTitle } from '@nextblock-cms/ui';
+
+import { getSiteScriptRevisions, getSiteScripts } from './actions';
+import SiteScriptManager from './components/SiteScriptManager';
+
+export default async function SiteScriptsSettingsPage() {
+  const [scripts, revisions] = await Promise.all([getSiteScripts(), getSiteScriptRevisions()]);
+
+  return (
+    <div className="mx-auto max-w-5xl space-y-6">
+      <Card>
+        <CardHeader>
+          <CardTitle>Site Scripts</CardTitle>
+          <CardDescription>
+            JavaScript that runs on every page of the public site — animation helpers, chat widgets,
+            third-party embeds. Each script is injected with the page&apos;s Content-Security-Policy
+            nonce, so it runs without weakening the site&apos;s security headers. Disabled scripts are
+            never sent to visitors. Every change is logged and can be rolled back from the history
+            below.
+          </CardDescription>
+        </CardHeader>
+        <CardContent>
+          <SiteScriptManager initialRevisions={revisions} initialScripts={scripts} />
+        </CardContent>
+      </Card>
+
+      <Card>
+        <CardHeader>
+          <CardTitle>Where else code can live</CardTitle>
+        </CardHeader>
+        <CardContent className="space-y-2 text-sm text-muted-foreground">
+          <p>
+            <strong className="text-foreground">One page only?</strong> A rich-text block accepts an
+            inline <code>&lt;style&gt;</code> and <code>&lt;script&gt;</code> directly, so
+            page-specific effects do not need to live here.
+          </p>
+          <p>
+            <strong className="text-foreground">Site-wide styling?</strong> Use Themes &amp; CSS for
+            palettes and global stylesheets.
+          </p>
+          <p>
+            <strong className="text-foreground">Marketing or analytics tags?</strong> Put those under
+            Google Analytics instead — scripts there only fire once a visitor accepts cookies, which
+            is what consent law requires. Scripts on this page run unconditionally.
+          </p>
+        </CardContent>
+      </Card>
+    </div>
+  );
+}

package/templates/nextblock-template/app/cms/settings/taxes/page.tsx

@@ -1,21 +1,21 @@
-import { redirect } from 'next/navigation';
-import { verifyPackageOnline } from '@nextblock-cms/db/server';
-import { TaxesPage as TaxesPageUI } from '@nextblock-cms/ecommerce/server';
-
-export const metadata = {
-  title: 'Tax Settings | NextBlock™ CMS',
-};
-
-export default async function TaxesPageWrapper({
-  searchParams,
-}: {
-  searchParams?: Promise<{ success?: string }>;
-}) {
-  const isOnline = await verifyPackageOnline('ecommerce');
-
-  if (!isOnline) {
-    redirect('/cms/settings/packages');
-  }
-
-  return <TaxesPageUI searchParams={await searchParams} />;
-}
+import { redirect } from 'next/navigation';
+import { verifyPackageOnline } from '@nextblock-cms/db/server';
+import { TaxesPage as TaxesPageUI } from '@nextblock-cms/ecommerce/server';
+
+export const metadata = {
+  title: 'Tax Settings | NextBlock™ CMS',
+};
+
+export default async function TaxesPageWrapper({
+  searchParams,
+}: {
+  searchParams?: Promise<{ success?: string }>;
+}) {
+  const isOnline = await verifyPackageOnline('ecommerce');
+
+  if (!isOnline) {
+    redirect('/cms/settings/packages');
+  }
+
+  return <TaxesPageUI searchParams={await searchParams} />;
+}

package/templates/nextblock-template/app/cms/shipping/page.tsx

@@ -1,20 +1,20 @@
-import { redirect } from 'next/navigation';
-import { verifyPackageOnline } from '@nextblock-cms/db/server';
-import { ShippingPage as ShippingPageUI } from '@nextblock-cms/ecommerce/server';
-
-export default async function ShippingPage({
-    searchParams,
-}: {
-    searchParams: Promise<{ success?: string }>;
-}) {
-    const [isOnline, resolvedSearchParams] = await Promise.all([
-        verifyPackageOnline('ecommerce'),
-        searchParams,
-    ]);
-
-    if (!isOnline) {
-        redirect('/cms/settings/packages');
-    }
-
-    return <ShippingPageUI searchParams={resolvedSearchParams} />;
-}
+import { redirect } from 'next/navigation';
+import { verifyPackageOnline } from '@nextblock-cms/db/server';
+import { ShippingPage as ShippingPageUI } from '@nextblock-cms/ecommerce/server';
+
+export default async function ShippingPage({
+    searchParams,
+}: {
+    searchParams: Promise<{ success?: string }>;
+}) {
+    const [isOnline, resolvedSearchParams] = await Promise.all([
+        verifyPackageOnline('ecommerce'),
+        searchParams,
+    ]);
+
+    if (!isOnline) {
+        redirect('/cms/settings/packages');
+    }
+
+    return <ShippingPageUI searchParams={resolvedSearchParams} />;
+}

package/templates/nextblock-template/app/cms/users/components/DeleteUserButton.tsx

@@ -7,17 +7,17 @@ import { Trash2, ShieldAlert } from "lucide-react";
 import { deleteUserAndProfile } from "../actions";
 import { ConfirmationModal } from '../../components/ConfirmationModal';
 
-export function DeleteUserButtonClient({
-  userId,
-  userEmail,
-  currentAdminId,
-}: {
-  userId: string;
-  userEmail?: string;
-  currentAdminId?: string;
-}) {
-  void userEmail;
-  const [isPending, startTransition] = useTransition();
+export function DeleteUserButtonClient({
+  userId,
+  userEmail,
+  currentAdminId,
+}: {
+  userId: string;
+  userEmail?: string;
+  currentAdminId?: string;
+}) {
+  void userEmail;
+  const [isPending, startTransition] = useTransition();
   const [isModalOpen, setIsModalOpen] = useState(false);
 
   const handleDelete = () => {
@@ -68,4 +68,4 @@ export function DeleteUserButtonClient({
       />
     </>
   );
-}
+}