create-nextblock 0.14.0 → 0.14.2

package/templates/nextblock-template/lib/setup/system-config.ts

@@ -1,105 +1,105 @@
-import 'server-only';
-// Server-only read/write for the `system_configuration` singleton table.
-// Mirrors lib/privacy/settings.ts, but the data lives in a dedicated ADMIN-only
-// table (migration 00000000000030) rather than the public site_settings store.
-import { createClient, getServiceRoleSupabaseClient } from '@nextblock-cms/db/server';
-import type { Json } from '@nextblock-cms/db';
-import { DEFAULT_SYSTEM_CONFIGURATION, type SystemConfiguration } from './types';
-
-function asBool(value: unknown, fallback: boolean): boolean {
-  if (typeof value === 'boolean') return value;
-  if (typeof value === 'string') return value === 'true' || value === 'on';
-  return fallback;
-}
-
-function asSettings(value: unknown): Record<string, unknown> {
-  return value && typeof value === 'object' && !Array.isArray(value)
-    ? (value as Record<string, unknown>)
-    : {};
-}
-
-type ConfigPatch = Partial<Pick<SystemConfiguration, 'auto_accept_signups'>> & {
-  settings?: Record<string, unknown>;
-};
-
-/** Build a row payload, casting the loosely-typed settings object to the DB Json type. */
-function toRow(patch: ConfigPatch): {
-  auto_accept_signups?: boolean;
-  settings?: Json;
-  updated_at: string;
-} {
-  const row: { auto_accept_signups?: boolean; settings?: Json; updated_at: string } = {
-    updated_at: new Date().toISOString(),
-  };
-  if (patch.auto_accept_signups !== undefined) {
-    row.auto_accept_signups = patch.auto_accept_signups;
-  }
-  if (patch.settings !== undefined) {
-    row.settings = patch.settings as unknown as Json;
-  }
-  return row;
-}
-
-/**
- * Read the singleton config. Uses the service-role client so it works from any
- * context — including the anonymous public sign-up path, which must read
- * `auto_accept_signups` even though the table is otherwise ADMIN-only. Falls back to
- * safe defaults when the service-role key is absent (unconfigured instance).
- */
-export async function getSystemConfiguration(): Promise<SystemConfiguration> {
-  let supabase: ReturnType<typeof getServiceRoleSupabaseClient>;
-  try {
-    supabase = getServiceRoleSupabaseClient();
-  } catch {
-    return DEFAULT_SYSTEM_CONFIGURATION;
-  }
-
-  const { data, error } = await supabase
-    .from('system_configuration')
-    .select('auto_accept_signups, settings')
-    .eq('id', 1)
-    .maybeSingle();
-
-  if (error || !data) {
-    return DEFAULT_SYSTEM_CONFIGURATION;
-  }
-
-  return {
-    auto_accept_signups: asBool(data.auto_accept_signups, false),
-    settings: asSettings(data.settings),
-  };
-}
-
-/**
- * Persist a partial update via the request-scoped client. RLS enforces ADMIN — used
- * by the CMS security settings page. The wizard (which runs before any admin exists)
- * uses setSystemConfigurationServiceRole instead.
- */
-export async function updateSystemConfiguration(patch: ConfigPatch): Promise<void> {
-  const supabase = createClient();
-  const { error } = await supabase
-    .from('system_configuration')
-    .update(toRow(patch))
-    .eq('id', 1);
-
-  if (error) {
-    console.error('Error saving system configuration:', error.message);
-    throw new Error('Failed to save system configuration.');
-  }
-}
-
-/**
- * Seed/update the singleton with the service-role client (bypasses RLS). Used by the
- * /setup wizard before the first admin exists.
- */
-export async function setSystemConfigurationServiceRole(patch: ConfigPatch): Promise<void> {
-  const supabase = getServiceRoleSupabaseClient();
-  const { error } = await supabase
-    .from('system_configuration')
-    .upsert({ id: 1, ...toRow(patch) });
-
-  if (error) {
-    console.error('Error seeding system configuration:', error.message);
-    throw new Error('Failed to seed system configuration.');
-  }
-}
+import 'server-only';
+// Server-only read/write for the `system_configuration` singleton table.
+// Mirrors lib/privacy/settings.ts, but the data lives in a dedicated ADMIN-only
+// table (migration 00000000000030) rather than the public site_settings store.
+import { createClient, getServiceRoleSupabaseClient } from '@nextblock-cms/db/server';
+import type { Json } from '@nextblock-cms/db';
+import { DEFAULT_SYSTEM_CONFIGURATION, type SystemConfiguration } from './types';
+
+function asBool(value: unknown, fallback: boolean): boolean {
+  if (typeof value === 'boolean') return value;
+  if (typeof value === 'string') return value === 'true' || value === 'on';
+  return fallback;
+}
+
+function asSettings(value: unknown): Record<string, unknown> {
+  return value && typeof value === 'object' && !Array.isArray(value)
+    ? (value as Record<string, unknown>)
+    : {};
+}
+
+type ConfigPatch = Partial<Pick<SystemConfiguration, 'auto_accept_signups'>> & {
+  settings?: Record<string, unknown>;
+};
+
+/** Build a row payload, casting the loosely-typed settings object to the DB Json type. */
+function toRow(patch: ConfigPatch): {
+  auto_accept_signups?: boolean;
+  settings?: Json;
+  updated_at: string;
+} {
+  const row: { auto_accept_signups?: boolean; settings?: Json; updated_at: string } = {
+    updated_at: new Date().toISOString(),
+  };
+  if (patch.auto_accept_signups !== undefined) {
+    row.auto_accept_signups = patch.auto_accept_signups;
+  }
+  if (patch.settings !== undefined) {
+    row.settings = patch.settings as unknown as Json;
+  }
+  return row;
+}
+
+/**
+ * Read the singleton config. Uses the service-role client so it works from any
+ * context — including the anonymous public sign-up path, which must read
+ * `auto_accept_signups` even though the table is otherwise ADMIN-only. Falls back to
+ * safe defaults when the service-role key is absent (unconfigured instance).
+ */
+export async function getSystemConfiguration(): Promise<SystemConfiguration> {
+  let supabase: ReturnType<typeof getServiceRoleSupabaseClient>;
+  try {
+    supabase = getServiceRoleSupabaseClient();
+  } catch {
+    return DEFAULT_SYSTEM_CONFIGURATION;
+  }
+
+  const { data, error } = await supabase
+    .from('system_configuration')
+    .select('auto_accept_signups, settings')
+    .eq('id', 1)
+    .maybeSingle();
+
+  if (error || !data) {
+    return DEFAULT_SYSTEM_CONFIGURATION;
+  }
+
+  return {
+    auto_accept_signups: asBool(data.auto_accept_signups, false),
+    settings: asSettings(data.settings),
+  };
+}
+
+/**
+ * Persist a partial update via the request-scoped client. RLS enforces ADMIN — used
+ * by the CMS security settings page. The wizard (which runs before any admin exists)
+ * uses setSystemConfigurationServiceRole instead.
+ */
+export async function updateSystemConfiguration(patch: ConfigPatch): Promise<void> {
+  const supabase = createClient();
+  const { error } = await supabase
+    .from('system_configuration')
+    .update(toRow(patch))
+    .eq('id', 1);
+
+  if (error) {
+    console.error('Error saving system configuration:', error.message);
+    throw new Error('Failed to save system configuration.');
+  }
+}
+
+/**
+ * Seed/update the singleton with the service-role client (bypasses RLS). Used by the
+ * /setup wizard before the first admin exists.
+ */
+export async function setSystemConfigurationServiceRole(patch: ConfigPatch): Promise<void> {
+  const supabase = getServiceRoleSupabaseClient();
+  const { error } = await supabase
+    .from('system_configuration')
+    .upsert({ id: 1, ...toRow(patch) });
+
+  if (error) {
+    console.error('Error seeding system configuration:', error.message);
+    throw new Error('Failed to seed system configuration.');
+  }
+}

package/templates/nextblock-template/lib/setup/types.ts

@@ -1,18 +1,18 @@
-// Pure, client-safe types for the system_configuration singleton.
-// No server-only dependencies — importable from client and server modules.
-
-export interface SystemConfiguration {
-  /**
-   * When true, new public sign-ups skip outbound email verification: the signup
-   * route creates an already-confirmed account via the service role instead of
-   * relying on an SMTP confirmation link. Default false (defense-in-depth).
-   */
-  auto_accept_signups: boolean;
-  /** Forward-compatible feature toggles. Never holds secrets. */
-  settings: Record<string, unknown>;
-}
-
-export const DEFAULT_SYSTEM_CONFIGURATION: SystemConfiguration = {
-  auto_accept_signups: false,
-  settings: {},
-};
+// Pure, client-safe types for the system_configuration singleton.
+// No server-only dependencies — importable from client and server modules.
+
+export interface SystemConfiguration {
+  /**
+   * When true, new public sign-ups skip outbound email verification: the signup
+   * route creates an already-confirmed account via the service role instead of
+   * relying on an SMTP confirmation link. Default false (defense-in-depth).
+   */
+  auto_accept_signups: boolean;
+  /** Forward-compatible feature toggles. Never holds secrets. */
+  settings: Record<string, unknown>;
+}
+
+export const DEFAULT_SYSTEM_CONFIGURATION: SystemConfiguration = {
+  auto_accept_signups: false,
+  settings: {},
+};

package/templates/nextblock-template/lib/site-url.ts

@@ -1,48 +1,48 @@
-// Resolve the canonical public site URL across deploy channels WITHOUT requiring
-// NEXT_PUBLIC_URL to be set. On Vercel it falls back to the auto-provisioned
-// production URL, so a one-click deploy needs no URL input at all.
-//
-// Dependency-free and safe to import anywhere — server components, route handlers,
-// or client components — like lib/setup/env-status.ts. It only reads `process.env`:
-// NEXT_PUBLIC_* names are inlined into the browser bundle at build time, the others
-// resolve server-side only (and are simply absent — harmless — in the browser).
-
-const stripTrailingSlash = (value: string): string => value.replace(/\/+$/, '');
-
-/**
- * Vercel always sets a production domain (even on preview deployments):
- * `VERCEL_PROJECT_PRODUCTION_URL` server-side, and Vercel exposes the
- * framework-prefixed `NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL` to the browser
- * bundle at build time. Neither includes the protocol. We prefer the production URL
- * over the per-deployment `VERCEL_URL` so absolute links (sitemap, canonical, OG)
- * stay stable across deploys.
- */
-function vercelProductionUrl(): string {
-  const host =
-    process.env.NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL?.trim() ||
-    process.env.VERCEL_PROJECT_PRODUCTION_URL?.trim();
-  return host ? `https://${stripTrailingSlash(host)}` : '';
-}
-
-/**
- * Canonical absolute site origin (e.g. `https://example.com`), no trailing slash.
- * Precedence: explicit `NEXT_PUBLIC_URL` → Vercel production URL → `fallback`.
- */
-export function resolveSiteUrl(fallback = 'http://localhost:3000'): string {
-  const explicit = process.env.NEXT_PUBLIC_URL?.trim();
-  if (explicit) return stripTrailingSlash(explicit);
-
-  const vercel = vercelProductionUrl();
-  if (vercel) return vercel;
-
-  return stripTrailingSlash(fallback);
-}
-
-/**
- * True when a real, production-intended site URL is available (an explicit
- * `NEXT_PUBLIC_URL` or the Vercel production URL) — i.e. {@link resolveSiteUrl}
- * is NOT returning the local-dev fallback. Use this to gate "URL not set" warnings.
- */
-export function hasResolvedSiteUrl(): boolean {
-  return Boolean(process.env.NEXT_PUBLIC_URL?.trim() || vercelProductionUrl());
-}
+// Resolve the canonical public site URL across deploy channels WITHOUT requiring
+// NEXT_PUBLIC_URL to be set. On Vercel it falls back to the auto-provisioned
+// production URL, so a one-click deploy needs no URL input at all.
+//
+// Dependency-free and safe to import anywhere — server components, route handlers,
+// or client components — like lib/setup/env-status.ts. It only reads `process.env`:
+// NEXT_PUBLIC_* names are inlined into the browser bundle at build time, the others
+// resolve server-side only (and are simply absent — harmless — in the browser).
+
+const stripTrailingSlash = (value: string): string => value.replace(/\/+$/, '');
+
+/**
+ * Vercel always sets a production domain (even on preview deployments):
+ * `VERCEL_PROJECT_PRODUCTION_URL` server-side, and Vercel exposes the
+ * framework-prefixed `NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL` to the browser
+ * bundle at build time. Neither includes the protocol. We prefer the production URL
+ * over the per-deployment `VERCEL_URL` so absolute links (sitemap, canonical, OG)
+ * stay stable across deploys.
+ */
+function vercelProductionUrl(): string {
+  const host =
+    process.env.NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL?.trim() ||
+    process.env.VERCEL_PROJECT_PRODUCTION_URL?.trim();
+  return host ? `https://${stripTrailingSlash(host)}` : '';
+}
+
+/**
+ * Canonical absolute site origin (e.g. `https://example.com`), no trailing slash.
+ * Precedence: explicit `NEXT_PUBLIC_URL` → Vercel production URL → `fallback`.
+ */
+export function resolveSiteUrl(fallback = 'http://localhost:3000'): string {
+  const explicit = process.env.NEXT_PUBLIC_URL?.trim();
+  if (explicit) return stripTrailingSlash(explicit);
+
+  const vercel = vercelProductionUrl();
+  if (vercel) return vercel;
+
+  return stripTrailingSlash(fallback);
+}
+
+/**
+ * True when a real, production-intended site URL is available (an explicit
+ * `NEXT_PUBLIC_URL` or the Vercel production URL) — i.e. {@link resolveSiteUrl}
+ * is NOT returning the local-dev fallback. Use this to gate "URL not set" warnings.
+ */
+export function hasResolvedSiteUrl(): boolean {
+  return Boolean(process.env.NEXT_PUBLIC_URL?.trim() || vercelProductionUrl());
+}

package/templates/nextblock-template/lib/storage/provider.ts

@@ -1,66 +1,66 @@
-import 'server-only';
-
-import { resolveSupabaseServiceKey, resolveSupabaseUrl } from '../setup/env-status';
-
-// NextBlock has two storage backends:
-//
-//   's3'       — the existing S3-compatible path (Cloudflare R2, self-hosted MinIO, or
-//                even Supabase Storage's S3 endpoint when you create S3 access keys).
-//                Driven by the R2_* env vars + @aws-sdk/client-s3. Unchanged.
-//   'supabase' — native Supabase Storage via the supabase-js client and the injected
-//                service-role/secret key. NO S3 access keys required. This is what makes
-//                the one-click Vercel deploy work with zero storage configuration: the
-//                Marketplace integration injects the Supabase URL + secret key but NOT S3
-//                keys, so the S3 path can't authenticate — the native API can.
-//
-// The S3 path always wins when its keys are present, so local dev, Docker/MinIO, and BYO
-// Cloudflare R2 are completely unaffected. The native path is only chosen as the zero-key
-// fallback for a connected Supabase project.
-
-export type StorageBackend = 's3' | 'supabase';
-
-/** Which storage backend to use. Explicit STORAGE_PROVIDER wins; otherwise inferred. */
-export function getStorageBackend(): StorageBackend {
-  const explicit = process.env.STORAGE_PROVIDER?.trim().toLowerCase();
-  if (explicit === 'supabase') return 'supabase';
-  if (explicit === 's3' || explicit === 'r2' || explicit === 'minio') return 's3';
-
-  // S3/R2/MinIO wins whenever its credentials exist (local, Docker, BYO R2, or
-  // Supabase-S3-with-keys). Only fall back to native Supabase Storage when there are no
-  // S3 keys but a Supabase project IS connected (service key + URL) — the Vercel case.
-  const hasS3Keys = Boolean(
-    process.env.R2_ACCESS_KEY_ID && process.env.R2_SECRET_ACCESS_KEY,
-  );
-  if (hasS3Keys) return 's3';
-  if (resolveSupabaseServiceKey() && resolveSupabaseUrl()) return 'supabase';
-  return 's3';
-}
-
-/** The bucket name to read/write. Defaults to "media" on the native Supabase backend. */
-export function getStorageBucket(): string {
-  const explicit = process.env.STORAGE_BUCKET || process.env.R2_BUCKET_NAME;
-  if (explicit) return explicit;
-  return getStorageBackend() === 'supabase' ? 'media' : '';
-}
-
-/**
- * The public base URL objects are served from — what resolveMediaUrl() joins object keys
- * onto. An explicit R2 public/base URL always wins; otherwise, on the native Supabase
- * backend, derive Supabase Storage's public object endpoint
- * (`<project>/storage/v1/object/public/<bucket>`) so every display call site works with
- * zero extra config. Kept in sync with the CJS computation in next.config.js.
- */
-export function resolveMediaBaseUrl(): string {
-  const explicit =
-    process.env.NEXT_PUBLIC_R2_BASE_URL || process.env.NEXT_PUBLIC_R2_PUBLIC_URL;
-  if (explicit) return explicit.replace(/\/+$/, '');
-
-  if (getStorageBackend() === 'supabase') {
-    const url = resolveSupabaseUrl();
-    const bucket = getStorageBucket();
-    if (url && bucket) {
-      return `${url.replace(/\/+$/, '')}/storage/v1/object/public/${bucket}`;
-    }
-  }
-  return '';
-}
+import 'server-only';
+
+import { resolveSupabaseServiceKey, resolveSupabaseUrl } from '../setup/env-status';
+
+// NextBlock has two storage backends:
+//
+//   's3'       — the existing S3-compatible path (Cloudflare R2, self-hosted MinIO, or
+//                even Supabase Storage's S3 endpoint when you create S3 access keys).
+//                Driven by the R2_* env vars + @aws-sdk/client-s3. Unchanged.
+//   'supabase' — native Supabase Storage via the supabase-js client and the injected
+//                service-role/secret key. NO S3 access keys required. This is what makes
+//                the one-click Vercel deploy work with zero storage configuration: the
+//                Marketplace integration injects the Supabase URL + secret key but NOT S3
+//                keys, so the S3 path can't authenticate — the native API can.
+//
+// The S3 path always wins when its keys are present, so local dev, Docker/MinIO, and BYO
+// Cloudflare R2 are completely unaffected. The native path is only chosen as the zero-key
+// fallback for a connected Supabase project.
+
+export type StorageBackend = 's3' | 'supabase';
+
+/** Which storage backend to use. Explicit STORAGE_PROVIDER wins; otherwise inferred. */
+export function getStorageBackend(): StorageBackend {
+  const explicit = process.env.STORAGE_PROVIDER?.trim().toLowerCase();
+  if (explicit === 'supabase') return 'supabase';
+  if (explicit === 's3' || explicit === 'r2' || explicit === 'minio') return 's3';
+
+  // S3/R2/MinIO wins whenever its credentials exist (local, Docker, BYO R2, or
+  // Supabase-S3-with-keys). Only fall back to native Supabase Storage when there are no
+  // S3 keys but a Supabase project IS connected (service key + URL) — the Vercel case.
+  const hasS3Keys = Boolean(
+    process.env.R2_ACCESS_KEY_ID && process.env.R2_SECRET_ACCESS_KEY,
+  );
+  if (hasS3Keys) return 's3';
+  if (resolveSupabaseServiceKey() && resolveSupabaseUrl()) return 'supabase';
+  return 's3';
+}
+
+/** The bucket name to read/write. Defaults to "media" on the native Supabase backend. */
+export function getStorageBucket(): string {
+  const explicit = process.env.STORAGE_BUCKET || process.env.R2_BUCKET_NAME;
+  if (explicit) return explicit;
+  return getStorageBackend() === 'supabase' ? 'media' : '';
+}
+
+/**
+ * The public base URL objects are served from — what resolveMediaUrl() joins object keys
+ * onto. An explicit R2 public/base URL always wins; otherwise, on the native Supabase
+ * backend, derive Supabase Storage's public object endpoint
+ * (`<project>/storage/v1/object/public/<bucket>`) so every display call site works with
+ * zero extra config. Kept in sync with the CJS computation in next.config.js.
+ */
+export function resolveMediaBaseUrl(): string {
+  const explicit =
+    process.env.NEXT_PUBLIC_R2_BASE_URL || process.env.NEXT_PUBLIC_R2_PUBLIC_URL;
+  if (explicit) return explicit.replace(/\/+$/, '');
+
+  if (getStorageBackend() === 'supabase') {
+    const url = resolveSupabaseUrl();
+    const bucket = getStorageBucket();
+    if (url && bucket) {
+      return `${url.replace(/\/+$/, '')}/storage/v1/object/public/${bucket}`;
+    }
+  }
+  return '';
+}