jamdesk 1.1.205 → 1.1.207

package/vendored/lib/theme-preview-context.tsx

@@ -0,0 +1,39 @@
+'use client';
+
+import { createContext, useContext, type ReactNode } from 'react';
+import type { ThemeName } from '@/themes';
+
+export interface ThemePreviewValue {
+  /** Whether the picker may render. False for every project but jamdesk-docs. */
+  enabled: boolean;
+  /** The theme currently rendering — the previewed one when a cookie is active. */
+  activeTheme: ThemeName;
+  /** The project's own theme from docs.json, before any preview override. */
+  defaultTheme: ThemeName;
+}
+
+// Default is disabled: a consumer rendered without a provider (i.e. every
+// customer site) gets nothing.
+const ThemePreviewContext = createContext<ThemePreviewValue>({
+  enabled: false,
+  activeTheme: 'jam',
+  defaultTheme: 'jam',
+});
+
+export function ThemePreviewProvider({
+  children,
+  value,
+}: {
+  children: ReactNode;
+  value: ThemePreviewValue;
+}): React.ReactElement {
+  return (
+    <ThemePreviewContext.Provider value={value}>
+      {children}
+    </ThemePreviewContext.Provider>
+  );
+}
+
+export function useThemePreview(): ThemePreviewValue {
+  return useContext(ThemePreviewContext);
+}

package/vendored/lib/theme-preview.ts

@@ -0,0 +1,150 @@
+/**
+ * Theme preview gate — jamdesk-docs only.
+ *
+ * A visitor picks a theme from the header dropdown; the picker writes a cookie
+ * and reloads, and `app/layout.tsx` applies it by overriding `config.theme`
+ * before rendering DocsChrome. Everything in this file is pure so the entire
+ * gate can be tested without rendering or touching the environment.
+ *
+ * TWO OPERATIONAL INVARIANTS live here because nothing else in the tree records
+ * them:
+ *
+ * 1. KILL SWITCH — `THEME_PREVIEW_ENABLED`, read in `app/layout.tsx` through
+ *    `isThemePreviewEnvEnabled`. It is **ON BY DEFAULT**: unset, empty or any
+ *    unrecognised value leaves the picker live. Only `false`, `0`, `off` and
+ *    `no` (any case, surrounding whitespace ignored) disable it. Setting it
+ *    also stops the cookie being read, so visitors holding a `jd_theme` cookie
+ *    fall back to the project's own theme on their next load.
+ *
+ *    It is NOT a runtime toggle, and the rollback it buys is not a light one:
+ *    the variable is a Vercel env var read in the SHARED ROOT LAYOUT, so
+ *    flipping it takes a full ISR redeploy (`vercel --prod` from
+ *    `build-service`) across all ~93 tenants — the same fleet-wide surface the
+ *    2026-09-03 `ERR_REQUIRE_ESM` outage came through. Verify such a deploy
+ *    with `node scripts/smoke-tenants.mjs`, never a single URL. Prefer it to a
+ *    code revert, but budget for a deploy: there is no faster kill path.
+ *
+ * 2. CACHEABILITY — the response varies by the `jd_theme` cookie while
+ *    carrying NO `Vary: Cookie`, and the two hosts that serve the picker do
+ *    NOT share a cache posture:
+ *
+ *      - `jamdesk.com/docs` (apex, through the worker) is uncacheable end to
+ *        end — `private, no-cache, no-store` upstream, `cf-cache-status:
+ *        BYPASS` at the edge. Safe.
+ *      - `jamdesk-docs.jamdesk.app` (the ISR subdomain) serves `public,
+ *        max-age=0, must-revalidate` with NO `Vary`. The picker is live there
+ *        too: the host resolves to slug `jamdesk-docs` and the cookie is
+ *        written at `Path=/`. A shared cache on that host may serve one
+ *        visitor's previewed theme to another.
+ *
+ *    That second exposure is KNOWN and was accepted as cosmetic residual risk
+ *    — the payload is a theme on Jamdesk's own docs, the HTML carries nothing
+ *    visitor-specific, and the subdomain is not the surface prospects are sent
+ *    to. Do not add `Vary: Cookie` without revisiting that call. DO revisit it
+ *    if anything raises the stakes: a Cloudflare Cache Rule or `s-maxage` that
+ *    makes the apex shared-cacheable, extending the preview past jamdesk-docs,
+ *    or putting anything per-visitor in the response. A server component
+ *    cannot set response headers, so this docblock IS the mitigation — the
+ *    only thing that can go wrong with it is going stale.
+ */
+import { getAllThemes, type ThemeName } from '@/themes';
+
+/** Cookie the picker writes; read server-side in app/layout.tsx. */
+export const THEME_PREVIEW_COOKIE = 'jd_theme';
+
+/** The only project permitted to preview themes. */
+export const THEME_PREVIEW_SLUG = 'jamdesk-docs';
+
+// No lifetime constant on purpose: the picker writes a SESSION cookie (no
+// Max-Age), so a preview dies with the browser. The picker is desktop-only, so
+// a persisted preview would follow a visitor to mobile with no way to reset
+// it. The clear path still sends `Max-Age=0` — see ThemePreviewPicker's
+// applyTheme.
+
+// Built from the registry rather than using `isValidTheme`, which is a plain
+// `name in themes` check and therefore also returns true for inherited Object
+// keys ('constructor', 'toString'). Those would reach getTheme(), which falls
+// back to jam silently for unknown names but returns Object's own constructor
+// for 'constructor' — yielding data-theme="constructor" and no theme CSS.
+// A Set of the registry's own names is immune and picks up new themes for free.
+const VALID_THEME_NAMES: ReadonlySet<string> = new Set(
+  getAllThemes().map((theme) => theme.name),
+);
+
+/**
+ * Values of `THEME_PREVIEW_ENABLED` that turn the picker OFF. Anything else —
+ * including unset and empty — leaves it ON (see invariant 1 above). The spread
+ * matters: an operator reaching for a kill switch mid-incident types whichever
+ * of these comes to hand, and matching only `'false'` would let a successful
+ * deploy leave the feature live with no error anywhere.
+ */
+const DISABLING_VALUES: ReadonlySet<string> = new Set(['false', '0', 'off', 'no']);
+
+/**
+ * Whether the env kill switch leaves the picker enabled.
+ *
+ * `.trim()` is load-bearing, not defensive noise: a `vercel env add` value that
+ * picks up a trailing newline is what silently 404'd every ISR subdomain via
+ * `ISR_MODE` (root CLAUDE.md), and the failure here is quieter still — an
+ * untrimmed `"false\n"` leaves the kill switch ON while the Vercel dashboard
+ * shows it set to false.
+ */
+export function isThemePreviewEnvEnabled(raw: string | undefined): boolean {
+  return !DISABLING_VALUES.has(raw?.trim().toLowerCase() ?? '');
+}
+
+/** The registry theme this string names, or null. The single validation point. */
+function parseThemeName(value: string | undefined | null): ThemeName | null {
+  const name = (value ?? '').trim().toLowerCase();
+  return VALID_THEME_NAMES.has(name) ? (name as ThemeName) : null;
+}
+
+/**
+ * A registry theme name, or `jam` for anything else. `config.theme` arrives
+ * from docs.json as an unvalidated string, so casting it straight to ThemeName
+ * would hand the picker a value that labels no row and matches no "Default"
+ * badge.
+ */
+export function toThemeName(value: string | undefined | null): ThemeName {
+  return parseThemeName(value) ?? 'jam';
+}
+
+interface ThemePreviewGate {
+  /** Resolved project slug from the x-project-slug header. */
+  projectSlug: string | null;
+  /** Whether the app is running in multi-tenant ISR mode. */
+  isIsr: boolean;
+  /** Kill switch, resolved from env by the caller so this stays pure. */
+  enabled: boolean;
+}
+
+export interface ThemePreviewInput extends ThemePreviewGate {
+  /** Raw cookie value, if present. */
+  cookieValue: string | undefined;
+}
+
+/**
+ * The theme a visitor has selected, or null to use the project's own theme.
+ * Every condition is re-checked here even though the caller also checks some
+ * of them — this function is the single place a preview can be granted.
+ */
+export function resolveThemePreview({
+  cookieValue,
+  projectSlug,
+  isIsr,
+  enabled,
+}: ThemePreviewInput): ThemeName | null {
+  if (!isThemePreviewEnabled({ projectSlug, isIsr, enabled })) return null;
+  if (!cookieValue) return null;
+
+  return parseThemeName(cookieValue);
+}
+
+/** Whether the picker UI may render at all. */
+export function isThemePreviewEnabled({
+  projectSlug,
+  isIsr,
+  enabled,
+}: ThemePreviewGate): boolean {
+  return enabled && isIsr && projectSlug === THEME_PREVIEW_SLUG;
+}

package/vendored/lib/unlock-audit.ts

@@ -0,0 +1,10 @@
+// Extracted from app/api/jd/unlock/route.ts: Next.js's route typegen requires
+// that a route.ts export ONLY the known route-convention symbols (GET, POST,
+// runtime, dynamic, ...) — any other export fails `tsc`'s check of
+// .next/types/app/**/route.ts with TS2344 ("does not satisfy the constraint
+// '{ [x: string]: never }'"). This constant is used by the route handler but
+// also needs to be assertable-against in tests, so it lives here instead.
+
+// Audit log tag emitted on every successful master-password unlock. Exported
+// so tests can assert exact format without duplicating the literal.
+export const MASTER_AUDIT_TAG = '[unlock] master-password used';

package/vendored/next.config.js

@@ -70,6 +70,25 @@ const nextConfig = {
       '../build/polyfills/polyfill-module': './lib/empty-polyfill.js',
       'next/dist/build/polyfills/polyfill-module': './lib/empty-polyfill.js',
     },
+    // Mirrors build-service/next.config.mjs. Turbopack has no equivalent of
+    // webpack's resolve.extensionAlias (https://github.com/vercel/next.js/issues/82945),
+    // so a relative `./foo.js` import whose real source is `./foo.ts` can fail
+    // to resolve. That is the convention every file in vendored/ uses, 120
+    // relative `.js` specifiers of it, including the lib/jwt-session.ts ->
+    // lib/public-paths-resolver.ts chain that made build-service fail
+    // deterministically. The workspace compiles the same tree, so it needs
+    // the same rule. Exempt from this file's keep-it-minimal rule: the
+    // 80s-compile warning above is about turbopack.root and resolution
+    // scope, and this is one regex pass over source text.
+    //
+    // vendored/ is copied wholesale into the workspace, so vendored/scripts
+    // lands at <workspace>/scripts and this relative path resolves. The
+    // loader is on the safeScripts allowlist in cli/scripts/vendor.js;
+    // turbopack-loader-config-drift.test.ts pins all of it together.
+    rules: {
+      '*.ts': { loaders: ['./scripts/turbopack-js-to-ts-loader.cjs'] },
+      '*.tsx': { loaders: ['./scripts/turbopack-js-to-ts-loader.cjs'] },
+    },
   },
   // Critical for fast builds
   experimental: {
@@ -87,6 +106,19 @@ const nextConfig = {
       '@radix-ui/react-tooltip',
     ],
   },
+  // `jamdesk dev --webpack` is an advertised fallback (src/index.ts), and
+  // webpack needs the same `.js`-means-`.ts` mapping the Turbopack rule above
+  // provides. Without it the escape hatch fails on the imports the escape
+  // hatch exists to work around.
+  webpack: (config) => {
+    config.resolve.extensionAlias = {
+      ...config.resolve.extensionAlias,
+      '.js': ['.ts', '.tsx', '.js'],
+      '.mjs': ['.mts', '.mjs'],
+      '.cjs': ['.cts', '.cjs'],
+    }
+    return config
+  },
 }
 
 export default nextConfig

package/vendored/schema/docs-schema.json

@@ -1567,6 +1567,18 @@
                     "additionalProperties": false,
                     "description": "Configure user interaction behavior with navigation and links"
                 },
+                "localization": {
+                    "type": "object",
+                    "properties": {
+                        "autoRedirect": {
+                            "type": "boolean",
+                            "default": false,
+                            "description": "Redirect a first-time visitor from a locale root to the language matching their Accept-Language header. Requires navigation.languages. Bots are never redirected. Defaults to `false`"
+                        }
+                    },
+                    "additionalProperties": false,
+                    "description": "Control how visitors reach the translated version of your docs"
+                },
                 "metadata": {
                     "type": "object",
                     "properties": {
@@ -1833,6 +1845,9 @@
                 "metadata": {
                     "$ref": "#/anyOf/0/properties/metadata"
                 },
+                "localization": {
+                    "$ref": "#/anyOf/0/properties/localization"
+                },
                 "chat": {
                     "$ref": "#/anyOf/0/properties/chat"
                 },
@@ -1954,6 +1969,9 @@
                 "metadata": {
                     "$ref": "#/anyOf/0/properties/metadata"
                 },
+                "localization": {
+                    "$ref": "#/anyOf/0/properties/localization"
+                },
                 "chat": {
                     "$ref": "#/anyOf/0/properties/chat"
                 },
@@ -2075,6 +2093,9 @@
                 "metadata": {
                     "$ref": "#/anyOf/0/properties/metadata"
                 },
+                "localization": {
+                    "$ref": "#/anyOf/0/properties/localization"
+                },
                 "chat": {
                     "$ref": "#/anyOf/0/properties/chat"
                 },

package/vendored/scripts/turbopack-js-to-ts-loader.cjs

@@ -0,0 +1,51 @@
+/**
+ * Turbopack build-time source transform: strips the `.js` suffix off
+ * RELATIVE import/export/dynamic-import specifiers before Turbopack's own
+ * resolver sees them.
+ *
+ * Why this exists: this project's tsconfig.json sets
+ * `moduleResolution: "bundler"`, the TypeScript convention where source
+ * files are `.ts` but every relative import of them is written with a
+ * `.js` suffix (e.g. `import { x } from './foo.js'` for a file that is
+ * actually `./foo.ts` on disk). webpack supports this natively via
+ * `resolve.extensionAlias` (wired up in next.config.mjs's `webpack()`
+ * function). Turbopack has NO equivalent, documented, built-in support for
+ * this as of Next.js 16.3.x — see https://github.com/vercel/next.js/issues/82945
+ * ("Turbopack: support importing .ts/.tsx via .js extension"), which is
+ * open/unfixed upstream. In practice Turbopack resolves the VAST MAJORITY
+ * of this project's `.js`-suffixed relative imports fine through some
+ * internal inference, but was observed to throw a hard "Module not found"
+ * for specific files/subtrees (e.g. the whole lib/jwt-session.ts ->
+ * lib/public-paths-resolver.ts -> lib/{docs-types,glob-match,
+ * find-first-nav-page,language-utils}.ts chain added by the jwt docs-auth
+ * feature) — confirmed via a standalone unrs-resolver probe, and via
+ * removing the `.js` suffix by hand (which fixes resolution one hop at a
+ * time, confirming the failure is the extension-alias gap, not a real
+ * missing file). Rather than rewrite this project's whole import style
+ * (pervasive, deliberate convention — see tsconfig.json's
+ * `moduleResolution: "bundler"` and CLAUDE.md), this loader rewrites the
+ * `.js` -> (nothing) at Turbopack-compile time only. TypeScript itself,
+ * `tsc --noEmit`, vitest, and webpack builds are all UNAFFECTED (this file
+ * is wired into next.config.mjs's `turbopack.rules` only).
+ *
+ * Scoped to RELATIVE specifiers only (`./x.js`, `../x.js`) — never bare
+ * package specifiers — so a legitimate deep import of an npm package's own
+ * `.js` file (e.g. a subpath export) is never touched.
+ *
+ * Community-sourced workaround for the same open issue, adapted to be
+ * relative-imports-only (the referenced version was unscoped):
+ * https://github.com/vercel/next.js/issues/82945#issuecomment-3269958583
+ */
+
+// Matches: (import|export) ... from '<spec>'; and dynamic import('<spec>')
+// where <spec> starts with ./ or ../ and ends in .js/.jsx/.mjs, capturing
+// the quote character so it round-trips exactly.
+const RELATIVE_JS_SPECIFIER_RE =
+  /((?:from\s+|import\()\s*)(["'])(\.\.?\/[^"']+?)\.(m?js|jsx)\2/g;
+
+module.exports = function stripRelativeJsExtensions(source) {
+  return source.replace(
+    RELATIVE_JS_SPECIFIER_RE,
+    (_match, prefix, quote, specPath) => `${prefix}${quote}${specPath}${quote}`,
+  );
+};