SF-7: feat(datafn): add docs package#39
Conversation
|
Too many files changed for review. ( |
There was a problem hiding this comment.
Sorry @thyaravind, your pull request is larger than the review limit of 150000 diff characters
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (132)
📝 WalkthroughWalkthroughThis PR adds a complete Next.js documentation site for DataFn: app layouts/pages (MDX rendering, metadata, OpenGraph image), numerous MDX documentation pages and manifests, client-side MDX helpers (Mermaid, action buttons), build/config files (Next, Tailwind/PostCSS, TypeScript, Vercel), and a raw-markdown API route plus fumadocs source loader. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Browser Client
participant NextApp as Next.js App
participant Source as Fumadocs Source
participant Storage as MDX Files
participant FumaUI as Fumadocs UI
Client->>NextApp: GET /docs/some/path
NextApp->>Source: getPage(params.slug)
Source->>Storage: read MDX + meta (content/docs/*)
Storage-->>Source: MDX body, toc, frontmatter
Source-->>NextApp: page object { body, data, toc, path }
NextApp->>FumaUI: render DocsLayout + MDX components
FumaUI-->>NextApp: rendered HTML
NextApp-->>Client: HTML response
Note over Client,NextApp: Client clicks "Copy Markdown"
Client->>NextApp: LLMCopyButton event (fetch markdownUrl)
NextApp->>NextApp: fetch cached markdown -> copy to clipboard
NextApp-->>Client: success feedback
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested labels
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
|
Review Summary by QodoAdd comprehensive DataFn documentation site with Fumadocs MDX
WalkthroughsDescription• Add comprehensive datafn/docs documentation site with Fumadocs MDX configuration • Include complete DFQL language reference covering queries, mutations, filters, aggregations, pagination, sorting, transactions, and schema definitions • Document DataFn client setup, configuration, signals, queries, mutations, events, and framework adapters (Svelte, React, Vue, Solid, Angular) • Document DataFn server setup, authorization, validation, rate limiting, WebSocket configuration, and database adapters (Drizzle, Memory, Custom) • Document sync architecture including pull/push operations, offline-first model, clone/clone-up, hydration, and sharing permission lifecycle • Document storage layer with adapter interface, IndexedDB and memory implementations, and custom adapter development • Document advanced features including change tracking, error handling, security measures, guards, debouncing, and idempotency • Document plugin system with before/after hooks and client search plugin • Document multi-tenancy, capabilities system (timestamps, audit, trash, archivable, shareable), and sharing permissions v2 (SPV2) • Add AI-powered page action components for copying markdown and accessing external tools (GitHub, Scira, ChatGPT, Claude, Cursor) • Configure global styling with Tailwind CSS and Fumadocs UI theme • Set up TypeScript configuration with path aliases for documentation build Diagramflowchart LR
A["datafn/docs<br/>Documentation Site"] --> B["Fumadocs MDX<br/>Configuration"]
A --> C["Content<br/>Documentation"]
A --> D["Components<br/>AI Actions"]
B --> E["source.config.ts<br/>MDX Setup"]
B --> F["lib/source.ts<br/>Loader"]
C --> G["DFQL<br/>Language Ref"]
C --> H["Client<br/>Setup & API"]
C --> I["Server<br/>Setup & API"]
C --> J["Sync<br/>Architecture"]
C --> K["Storage<br/>Layer"]
C --> L["Advanced<br/>Features"]
D --> M["LLMCopyButton<br/>ViewOptions"]
File Changes1. datafn/docs/source.config.ts
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Code Review by Qodo
1.
|
There was a problem hiding this comment.
2 issues found across 132 files
Note: This PR contains a large number of files. cubic only reviews up to 75 files per PR, so some files may not have been reviewed.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="datafn/docs/content/docs/dfql/queries.mdx">
<violation number="1" location="datafn/docs/content/docs/dfql/queries.mdx:122">
P3: The execution-strategy table is inaccurate: it omits several query shapes that force `IN_MEMORY` and overstates when `FULL_PUSHDOWN` is selected.</violation>
</file>
<file name="datafn/docs/content/docs/dfql/pagination.mdx">
<violation number="1" location="datafn/docs/content/docs/dfql/pagination.mdx:118">
P2: The docs claim `offset` is ignored when `cursor` is provided, but the in-memory execution path still applies `offset` after cursor slicing. Update this sentence to reflect the actual behavior (or warn that combining them will still skip items) so users aren't misled.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
Actionable comments posted: 13
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (15)
datafn/docs/.gitignore-1-1 (1)
1-1:⚠️ Potential issue | 🟡 MinorAdd
.nextandoutdirectories to the.gitignore.This is a Next.js project with
next.config.mjsand a build command that generates.next/in thedatafn/docsdirectory. The current.gitignoreonly contains.vercel. Add.nextandout/to prevent build artifacts from being committed:.vercel .next out/The root
.gitignoredoes not cover these patterns for the docs subdirectory.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/.gitignore` at line 1, Update the docs .gitignore to include Next.js build and export artifacts by adding the patterns ".next" and "out/" alongside the existing ".vercel" entry in the datafn/docs/.gitignore so build outputs from next.config.mjs (the .next directory) and static export (out/) are ignored and not committed.datafn/docs/content/docs/documentation/index.mdx-108-109 (1)
108-109:⚠️ Potential issue | 🟡 MinorFilter operator syntax is inconsistent with other docs in this PR.
This page uses
$eq, while other new pages useeq. Please standardize on one DFQL operator style to avoid confusing readers and broken copy/paste examples.Proposed consistency fix (if `eq` is canonical)
- filters: { completed: { $eq: false } }, + filters: { completed: { eq: false } }, ... - filters: { completed: { $eq: false } }, + filters: { completed: { eq: false } },Also applies to: 115-116
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/index.mdx` around lines 108 - 109, The filter uses the BSON-style operator "$eq" which is inconsistent with the rest of the docs; change the operator to the canonical DFQL form "eq" in the filters object (e.g., replace filters: { completed: { $eq: false } } with filters: { completed: { eq: false } } ) and apply the same replacement for the other occurrence that mirrors this example (also update any similar uses of "$eq" to "eq"); ensure keys like filters, completed, sort and sort entries ("priority:asc", "id:asc") remain unchanged.datafn/docs/content/docs/documentation/server/websockets.mdx-94-94 (1)
94-94:⚠️ Potential issue | 🟡 MinorUse a consistent argument name for
handlePong.The earlier snippet passes
ws, but this line usesclient. Align this tohandlePong(ws)to avoid copy/paste mistakes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/server/websockets.mdx` at line 94, The docs use inconsistent parameter names for handlePong: earlier snippets call server.websocketHandler.handlePong(ws) but the line at step 3 uses client; update the step to call server.websocketHandler.handlePong(ws) so the argument name matches the prior examples and avoids copy/paste errors, referencing the handlePong method and the ws variable.datafn/docs/content/docs/documentation/server/rest-api.mdx-26-30 (1)
26-30:⚠️ Potential issue | 🟡 MinorExample should match the stated URL-encoding requirement.
The text says
qmust be URL-encoded JSON, but the sample uses raw JSON. Please update the example to an encoded query string to avoid malformed request copy/paste.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/server/rest-api.mdx` around lines 26 - 30, The example GET request uses raw JSON for the q query parameter but the docs require URL-encoded JSON; update the example so the q value is URL-encoded (percent-encoded) JSON instead of raw braces, e.g. encode the payload {"filters":{"status":{"$eq":"active"}},"limit":10} and replace the path in the sample `GET /datafn/resources/tasks?q=...` accordingly so the q parameter contains the percent-encoded string; ensure the text still references the `q` query parameter and DFQL query parameters.datafn/docs/content/docs/reference/server/execution.mdx-28-28 (1)
28-28:⚠️ Potential issue | 🟡 MinorUse
filters(plural) in the classification rule.This line uses
filter.id.$eq, which is inconsistent with the documented query shape elsewhere (filters). Please align naming to avoid API confusion.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/server/execution.mdx` at line 28, The table entry uses the singular key `filter.id.$eq` but the API and docs use `filters`; update the classification rule example to use `filters.id.$eq` so it matches the documented query shape (search for the table row containing "Find by ID" and the string `filter.id.$eq` and replace it with `filters.id.$eq`).datafn/docs/content/docs/reference/server/execution.mdx-18-18 (1)
18-18:⚠️ Potential issue | 🟡 MinorDocumentation uses invalid TypeScript notation—update to match actual implementation.
The documentation on line 18 simplifies the type as
Map<string, Map<string, Record>>, butRecordrequires type parameters. The actual MemoryStore implementation (memory-store.ts:8) usesRecord<string, Record<string, Record<string, unknown>>>. Update the documentation to use valid TypeScript:Map<string, Map<string, Record<string, unknown>>>.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/server/execution.mdx` at line 18, The docs line describing the in-memory store uses an invalid TypeScript type; update the sentence to match the actual MemoryStore implementation by replacing `Map<string, Map<string, Record>>` with a valid type `Map<string, Map<string, Record<string, unknown>>>` so it aligns with the MemoryStore (memory-store.ts) shape and valid TypeScript syntax.datafn/docs/content/docs/documentation/client/setup.mdx-124-124 (1)
124-124:⚠️ Potential issue | 🟡 MinorPolish two wording issues in user-facing docs.
Line 124 reads as a sentence fragment after the dash, and Line 161 should hyphenate “Svelte-readable stores.”
Also applies to: 161-161
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/client/setup.mdx` at line 124, Fix two wording issues: make the clonePageSize bullet a complete sentence (referencing the `clonePageSize` option) by turning the fragment after the dash into a full sentence like "Page size for paginated clone requests; can be a single number or a per-resource map (e.g., { todos: 500, users: 200 })." and hyphenate "Svelte-readable stores" wherever that phrase appears (search for the exact phrase "Svelte readable stores" and change it to "Svelte-readable stores") so both user-facing lines (`clonePageSize` and the Svelte-readable stores mention) read correctly.datafn/docs/content/docs/reference/client/events.mdx-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorUse one filter type name consistently.
Lines 15 and 82 reference
EventFilter, but the documented type isDatafnEventFilter. Align these names to prevent copy/paste confusion.✏️ Suggested doc fix
- subscribe(handler: EventHandler, filter?: EventFilter): () => void; + subscribe(handler: EventHandler, filter?: DatafnEventFilter): () => void; -function matchesFilter(event: DatafnEvent, filter?: EventFilter): boolean; +function matchesFilter(event: DatafnEvent, filter?: DatafnEventFilter): boolean;Also applies to: 82-82
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/client/events.mdx` at line 15, The docs use two different filter type names causing confusion; update the signature and all references to use a single consistent type name (replace occurrences of EventFilter with DatafnEventFilter or vice versa) so the documented type matches the API; specifically update the subscribe method signature (subscribe(handler: EventHandler, filter?: EventFilter)) and the other reference (around the second occurrence) to the chosen canonical type name (DatafnEventFilter) so examples and typings align with the actual EventHandler/EventFilter types.datafn/docs/content/docs/documentation/storage/custom.mdx-17-17 (1)
17-17:⚠️ Potential issue | 🟡 MinorKeep constructor usage consistent across examples.
The interface example shows
CustomStorageAdapterwithout constructor params, but Line 161 instantiates it withnamespace. Align both snippets to avoid copy/paste type errors.Also applies to: 161-162
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/storage/custom.mdx` at line 17, The class example for CustomStorageAdapter is inconsistent with its use: add a constructor to the CustomStorageAdapter class signature that accepts the same parameter used where it’s instantiated (e.g., namespace) and store it on the instance so the class implements DatafnStorageAdapter and matches the usage; update the class definition (CustomStorageAdapter, constructor) to accept and assign the namespace parameter or alternatively remove the namespace from the instantiation so both snippets match—prefer adding a constructor(namespace: string) to the class example to align with the existing instantiation.datafn/docs/content/docs/documentation/database/drizzle.mdx-81-81 (1)
81-81:⚠️ Potential issue | 🟡 MinorFix relation terminology typo.
Line 81 says “many-many relations”; this should be “many-to-many relations” for correctness and readability.
✏️ Suggested doc fix
-- Join tables for many-many relations. +- Join tables for many-to-many relations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/database/drizzle.mdx` at line 81, Replace the incorrect phrase "many-many relations" with the correct "many-to-many relations" in the documentation sentence "Join tables for many-many relations."; search for and update any other occurrences of "many-many" in the same document (e.g., the line containing that exact sentence) to ensure consistent terminology.datafn/docs/content/docs/documentation/storage/custom.mdx-133-137 (1)
133-137:⚠️ Potential issue | 🟡 MinorAwait the write operation in
upsertRecord.Line 133 starts an async DB write but does not
awaitit. This can cause non-deterministic sequencing in callers.✅ Suggested fix
- this.db.run( + await this.db.run( `INSERT INTO ${resource} (${keys.join(", ")}) VALUES (${placeholders}) ON CONFLICT(id) DO UPDATE SET ${updates}`, values, );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/storage/custom.mdx` around lines 133 - 137, In upsertRecord, the async database write using this.db.run(...) is not awaited; change the call in the upsertRecord function to await this.db.run(`INSERT INTO ${resource} (${keys.join(", ")}) VALUES (${placeholders}) ON CONFLICT(id) DO UPDATE SET ${updates}`, values) so the operation completes before the function returns (and propagate or handle any errors as appropriate).datafn/docs/content/docs/documentation/server/setup.mdx-232-239 (1)
232-239:⚠️ Potential issue | 🟡 MinorClarify async vs synchronous error behavior.
Line 234 states that
createDatafnServer()"throws synchronously" on schema validation failure, but the example on line 48 usesawait createDatafnServer(), indicating it's an async function. This could confuse readers about when and how errors are thrown.Consider clarifying whether the schema validation happens during the async initialization (rejecting the promise) or if there's a synchronous phase before the async operations begin.
📝 Suggested clarification
## Schema Validation -The schema is validated at startup using `validateSchema()`. If validation fails, `createDatafnServer()` throws synchronously with a descriptive error: +The schema is validated at startup using `validateSchema()`. If validation fails, `createDatafnServer()` rejects with a descriptive error:Schema validation failed:
Details
</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@datafn/docs/content/docs/documentation/server/setup.mdxaround lines 232 -
239, Update the wording to clarify that schema validation performed by
validateSchema() happens during createDatafnServer()'s async initialization and
will cause the returned Promise to reject (so awaiting createDatafnServer() will
throw via rejected promise), rather than a synchronous throw; mention
createDatafnServer() and validateSchema() by name and add a brief note advising
callers to handle the error with try/catch around await createDatafnServer() or
.catch() on the Promise.</details> </blockquote></details> <details> <summary>datafn/docs/content/docs/dfql/schema/relations.mdx-263-267 (1)</summary><blockquote> `263-267`: _⚠️ Potential issue_ | _🟡 Minor_ **Remove duplicate heading.** There's a duplicate "## Querying Relations" heading. Line 263 already introduces the section, and line 267 repeats it. <details> <summary>📝 Suggested fix</summary> ```diff --- ## Querying Relations -DFQL supports querying and mutating relationships between records. Relations are defined in the schema and can be traversed in queries or modified through mutation operations. - -## Querying Relations ### Select Expansion Tokens🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/dfql/schema/relations.mdx` around lines 263 - 267, Remove the duplicate "## Querying Relations" heading that appears immediately after the introductory paragraph (the second occurrence of the "## Querying Relations" heading); keep the first instance and delete the repeated heading text so the section title appears only once.datafn/docs/content/docs/documentation/server/routes.mdx-112-129 (1)
112-129:⚠️ Potential issue | 🟡 Minor
limitsexample is missingmaxPullLimitwhile it is referenced later.Line 399 references
limits.maxPullLimit, but theGET /datafn/statusexample payload (Lines 124-128) omits it. Please align these sections so the status contract is self-consistent.✏️ Suggested doc fix
limits: { maxLimit: 100, maxTransactSteps: 100, + maxPullLimit: 1000, maxPayloadBytes: 5242880 },Also applies to: 399-399
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/server/routes.mdx` around lines 112 - 129, The example JSON for the GET /datafn/status response is missing the limits.maxPullLimit field referenced elsewhere; update the example payload in the documentation (the GET /datafn/status example object) to include a maxPullLimit entry under result.limits (e.g., alongside maxLimit, maxTransactSteps, maxPayloadBytes) so that limits.maxPullLimit exists and matches the expected type and value used later in the docs; ensure you modify the example object that contains schemaHash, capabilities and limits to add the maxPullLimit property.datafn/docs/content/docs/reference/core/search-provider.mdx-103-106 (1)
103-106:⚠️ Potential issue | 🟡 MinorFallback behavior wording is inconsistent with the documented contract.
Line 105 says fallback merges by score, but
search()(Lines 40-50) returns only IDs. Please clarify fallback ordering semantics to avoid implying score availability where none is documented.✏️ Suggested doc fix
-If not implemented, DataFn falls back to calling `search()` per resource and merging results by score. +If not implemented, DataFn falls back to calling `search()` per resource and combining results using provider/native ordering (since `search()` returns IDs, not explicit scores).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/core/search-provider.mdx` around lines 103 - 106, The doc's fallback wording is inconsistent: update the Cross-resource search paragraph to remove "merging results by score" and instead state the actual fallback ordering semantics given that search() (and client.search()) return only IDs — e.g., "DataFn falls back to calling search() per resource and concatenating/ordering results deterministically (by resource priority or stable resource name order) since scores are not available." Also ensure the description of search()/client.search() remains clear that only IDs are returned so the fallback behavior matches that contract.
🧹 Nitpick comments (16)
datafn/docs/app/not-found.tsx (1)
1-8: Consider using Tailwind CSS classes instead of inline styles.The 404 page is functional but uses inline styles. For consistency with the project's styling approach (Tailwind CSS v4), consider refactoring to use utility classes.
♻️ Proposed refactor using Tailwind CSS
export default function NotFound() { return ( - <div style={{ textAlign: "center", padding: "4rem" }}> - <h1>404 - Page Not Found</h1> - <p>The page you are looking for does not exist.</p> + <div className="text-center p-16"> + <h1 className="text-4xl font-bold mb-4">404 - Page Not Found</h1> + <p className="text-gray-600">The page you are looking for does not exist.</p> </div> ); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/app/not-found.tsx` around lines 1 - 8, The NotFound component uses inline styles; replace them with Tailwind utility classes: remove the style prop on the root div in the NotFound function and apply classes such as "text-center", "py-16" or "p-16" (or "px-4 py-16" as preferred) to center content and add spacing, and use Tailwind heading/paragraph classes (e.g., "text-2xl font-semibold" for the h1 and "mt-4 text-base text-muted-foreground" for the p) to match project styling conventions.datafn/docs/app/global.css (1)
5-6: Fragile relative path for theme tokens.The relative path
../../../packages/docs-theme/src/tokens.cssis brittle and will break if the directory structure changes. The comment acknowledges this is meant to reference@superfunctions/docs-theme/tokens.css. Once the workspace resolution blocker mentioned in the PR description is resolved, consider switching to the package import:-/* Shared theme package source: `@superfunctions/docs-theme/tokens.css` */ -@import "../../../packages/docs-theme/src/tokens.css"; +@import "@superfunctions/docs-theme/tokens.css";🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/app/global.css` around lines 5 - 6, Replace the fragile relative import "../../../packages/docs-theme/src/tokens.css" with the package import "@superfunctions/docs-theme/tokens.css" in the CSS where tokens are imported (the line currently importing tokens.css); keep the existing comment about the shared theme, and switch to the package path once the workspace resolution blocker is resolved so the import uses `@superfunctions/docs-theme/tokens.css` instead of the relative path.datafn/docs/package.json (1)
32-33:autoprefixeris unnecessary with Tailwind CSS v4.Tailwind CSS v4 uses Lightning CSS internally which handles vendor prefixes automatically. The
autoprefixerdependency can be removed.♻️ Suggested change
"devDependencies": { "@types/mdx": "^2", "@types/node": "^22", "@types/react": "^19", "@types/react-dom": "^19", - "autoprefixer": "^10", "postcss": "^8", "typescript": "^5" }As per coding guidelines from Tailwind v4 documentation: "Built-in Lightning CSS integration handles vendor prefixes, nesting, minification, and imports automatically. No need for separate PostCSS plugins like autoprefixer."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/package.json` around lines 32 - 33, The package.json currently lists "autoprefixer" which is unnecessary with Tailwind CSS v4; remove the "autoprefixer" entry from the dependencies section (leaving "postcss" if still required) and update the lockfile by running your package manager (npm/yarn/pnpm) to remove it from the install graph; verify there are no explicit uses of autoprefixer in PostCSS config files (e.g., postcss.config.js) and remove any references to the "autoprefixer" plugin if present.datafn/docs/app/layout.config.tsx (1)
6-10: Consider parameterizing the branch for different environments.The
branchis hardcoded to"dev". If docs are deployed from different branches (e.g.,mainfor production), GitHub "Edit on GitHub" links will point to the wrong branch.💡 Suggested approach
+const DOCS_BRANCH = process.env.DOCS_GIT_BRANCH || "dev"; + export const gitConfig: DocsGitConfig = { user: "21nCo", repo: "super-functions", - branch: "dev", + branch: DOCS_BRANCH, };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/app/layout.config.tsx` around lines 6 - 10, The gitConfig currently hardcodes branch = "dev" which breaks "Edit on GitHub" links for other environments; update the gitConfig creation (symbol: gitConfig of type DocsGitConfig) to read the branch from configuration or an environment variable (e.g., process.env.DOCS_GIT_BRANCH or a small helper that maps NODE_ENV to a branch) and fall back to "dev" if unset, so the branch value is parameterized per environment and used wherever gitConfig.branch is referenced.datafn/docs/content/docs/reference/client/config.mdx (1)
166-166: Clarify the return type documentation.Line 166 states "Each method returns a
DatafnEnvelopeas a plain object," but the interface definition above (lines 154-164) shows each method returningPromise<unknown>. Consider rewording to clarify that the resolved value is aDatafnEnvelope:-Each method returns a `DatafnEnvelope` as a plain object. +Each method returns a Promise that resolves to a `DatafnEnvelope` plain object.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/client/config.mdx` at line 166, Update the sentence that currently reads "Each method returns a `DatafnEnvelope` as a plain object" to clarify that the methods return a Promise that resolves to a `DatafnEnvelope` (i.e., the resolved value is a plain object conforming to the `DatafnEnvelope` interface), matching the interface signatures that show Promise<unknown>; reference the `DatafnEnvelope` type and the methods in the interface so the wording explicitly states "returns a Promise that resolves to a DatafnEnvelope."datafn/docs/content/docs/documentation/server/authorization.mdx (1)
191-204: Consider relocating Python handler architecture section.The "Python Handler Architecture" table (lines 191-204) documents the internal handler module structure for the Python SDK. This implementation detail doesn't directly relate to authorization concepts covered in the rest of this page.
Consider moving this section to a dedicated Python implementation reference page (e.g.,
/docs/reference/python/handlersor/docs/documentation/server/python-handlers) to improve topical coherence.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/server/authorization.mdx` around lines 191 - 204, Remove the "Python Handler Architecture" heading and its table (the block starting with "Python Handler Architecture" and listing handlers like handle_query, handle_mutation, handle_transact, handle_seed, handle_clone, handle_pull, handle_push) from the authorization page and create a new dedicated Python reference doc for it (e.g., a new markdown/MDX page titled "Python Handlers" under the Python reference/docs area); move the full table content into that new page, add a short cross-link from the original authorization page to the new reference page, and update any local links or sidebar/navigation entries to include the new page so the handlers' implementation details are documented in the correct topical area.datafn/docs/content/docs/documentation/storage/indexeddb.mdx (1)
69-73: Optional: Consider varying sentence structure in the numbered list.The numbered list items 3–5 begin with "Creates," which creates a repetitive pattern. While the content is clear and accurate, you could optionally vary the structure for stylistic flow.
✍️ Suggested rewording
1. Creates an object store for each resource (keyed by `id`). 2. Creates indices from the resource schema (e.g., fields listed in `indices`). -3. Creates foreign key indices inferred from relations. -4. Creates join stores for many-many relations with composite keys `[from, to]` and indices on both columns. -5. Creates the built-in `kv` store for key-value operations. +3. Infers and creates foreign key indices from relations. +4. Generates join stores for many-to-many relations with composite keys `[from, to]` and indices on both columns. +5. Initializes the built-in `kv` store for key-value operations.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/storage/indexeddb.mdx` around lines 69 - 73, The three list items that currently begin with "Creates" should be rephrased to reduce repetition: change item 3 to something like "Infers foreign key indices from relations" (referencing "foreign key indices"), item 4 to "Adds join stores for many-many relations with composite keys [from, to] and indices on both columns" (referencing "join stores" and the composite key), and item 5 to "Includes the built-in `kv` store for key-value operations" (referencing "`kv` store"); apply these wording changes in the numbered list to vary sentence structure while preserving meaning.datafn/docs/content/docs/documentation/client/signals.mdx (1)
142-142: Use a compound modifier for clarity.“readable stores” should be “readable-store” in this context.
Proposed wording tweak
-Use `@datafn/svelte` to convert signals to Svelte readable stores: +Use `@datafn/svelte` to convert signals to Svelte readable-store values:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/client/signals.mdx` at line 142, Update the wording in the sentence "Use `@datafn/svelte` to convert signals to Svelte readable stores:" to use the compound modifier "readable-store" for clarity (e.g., "Use `@datafn/svelte` to convert signals to Svelte readable-stores:"), so replace "readable stores" with "readable-store(s)" consistently in the phrase where it appears in the client/signals.mdx content.datafn/docs/content/docs/reference/client/svelte.mdx (1)
84-84: Hyphenate the compound modifier.“client-reference driven” should be “client-reference-driven”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/reference/client/svelte.mdx` at line 84, Update the phrase "client-reference driven" to the hyphenated compound "client-reference-driven" in the docs content (the sentence "Overload for client-reference driven signal creation."). Locate that exact string in the Svelte client reference doc (client/svelte.mdx) and replace it so the modifier is correctly hyphenated.datafn/docs/content/docs/dfql/filters.mdx (1)
120-120: Consider adding a reference for thelikeToRegExp()function.Line 120 mentions that
$likeand$ilikepatterns are "converted to regular expressions vialikeToRegExp()" in the client-side evaluator, but doesn't indicate where this utility is defined or documented. Consider adding a cross-reference to help developers find this function if they need to use it directly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/dfql/filters.mdx` at line 120, Add a cross-reference for the likeToRegExp() utility where the docs say "$like and $ilike patterns are converted to regular expressions via likeToRegExp()": mention where the function is defined (e.g., the client-side evaluator module or util file) and link or point to its API/docs page so developers can find its implementation and usage examples; reference the likeToRegExp symbol and the client-side evaluator to help locate the code.datafn/docs/content/docs/dfql/mutations.mdx (1)
185-189: Consider adding a deprecation timeline foruserIdfield.The migration note clearly states that
shareWith.userIdis deprecated in favor ofshareWith.principalId, but doesn't indicate when this deprecation was introduced or if there's a planned removal timeline. Adding this information would help developers prioritize migration work.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/dfql/mutations.mdx` around lines 185 - 189, Update the docs entry for shareWith to include a deprecation timeline for shareWith.userId: add when the deprecation was introduced, whether it will be removed (or under consideration), and any planned removal version or target date, and include recommended migration urgency; specifically edit the paragraph referencing shareWith.userId and principalId (and the Migration note) to state the deprecation start date/version and the expected removal timeline so callers of userId know how urgently to switch to principalId.datafn/docs/content/docs/documentation/database/transactions.mdx (1)
40-49: Clarify when explicitcommit()/rollback()methods should be used.The
TransactionAdapterinterface (line 43-45) exposes explicitcommit()androllback()methods, but line 49 states "The transaction commits automatically when the callback resolves." This creates ambiguity about when developers should call these methods explicitly versus relying on automatic behavior.Consider adding a note explaining:
- Whether explicit
commit()is ever necessary (or if it's a no-op when auto-commit will occur)- Whether explicit
rollback()is needed to abort mid-transaction, or if throwing an error is preferred- If these methods are primarily for advanced use cases
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/database/transactions.mdx` around lines 40 - 49, The docs are ambiguous about when to call TransactionAdapter.commit() and rollback(); update the paragraph around the TransactionAdapter interface to explicitly state that the transaction is auto-committed when the transaction callback resolves and auto-rolled back when the callback throws, that calling commit() is normally unnecessary (it will be a no-op if the callback completes and auto-commit occurs) but can be used in advanced scenarios to finalize a sub-step within the callback, and that rollback() can be used to abort mid-transaction programmatically (otherwise throwing from the callback will also trigger a rollback); reference the TransactionAdapter type and its commit()/rollback() methods and note these are for advanced or programmatic control rather than required for typical callback usage.datafn/docs/app/docs/[[...slug]]/page.tsx (1)
21-22: Avoidanyfor page metadata payloads.Using
as anyhere drops type guarantees for critical render/metadata fields. Prefer a typed page-data shape fromsource.getPage()(or a local interface) to catch docs schema drift early.Also applies to: 60-60
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/app/docs/`[[...slug]]/page.tsx around lines 21 - 22, Replace the unsafe "as any" cast on page.data with a proper typed interface or existing type from your page source (e.g., a PageData or the return type of source.getPage()) so you retain compile-time guarantees for fields used during render; specifically change the declaration "const data = page.data as any" to use that PageData type and update usages like MDX = data.body and the other occurrence at line ~60 to rely on typed properties (body, title, description, etc.) instead of any, or import/derive the type from the function that produces the page payload.datafn/docs/content/docs/documentation/storage/overview.mdx (1)
94-104: Remove unused import from example.The
nsimport is not used in this code example, which may confuse readers.📝 Suggested fix
import type { DatafnStorageFactory } from "@datafn/client"; -import { IndexedDbStorageAdapter, ns } from "@datafn/client"; +import { IndexedDbStorageAdapter } from "@datafn/client"; const storageFactory: DatafnStorageFactory = (namespace) => { return IndexedDbStorageAdapter.createForNamespace( "my-app", namespace, ); };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/storage/overview.mdx` around lines 94 - 104, The example imports an unused symbol `ns`; remove `ns` from the import list so only used symbols are imported (keep import of `IndexedDbStorageAdapter` and `DatafnStorageFactory`), e.g. update the import line that currently reads `import { IndexedDbStorageAdapter, ns } from "@datafn/client";` to exclude `ns` and leave other code (`storageFactory`, `IndexedDbStorageAdapter.createForNamespace`) unchanged.datafn/docs/content/docs/documentation/sync/sharing-sync-lifecycle.mdx (1)
54-59: Consider varying sentence structure for readability.Three consecutive sentences begin with "Device B", which can feel repetitive. Consider restructuring for better flow.
📝 Suggested fix
## Offline Example -- Device A (owner) shares a note while Device B (viewer) is offline. -- Device B later reconnects and runs pull. -- Device B receives the historical note as a backfill upsert. -- If owner revokes later, Device B receives a delete tombstone on the next pull. +- Device A (owner) shares a note while Device B (viewer) is offline. +- Upon reconnecting, Device B runs pull and receives the historical note as a backfill upsert. +- If the owner later revokes access, the next pull delivers a delete tombstone to Device B.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/documentation/sync/sharing-sync-lifecycle.mdx` around lines 54 - 59, The three bullet sentences under the "Offline Example" section are repetitive because each one starts with "Device B"; rewrite the bullets to vary sentence structure and improve flow by combining or reordering phrases (for example: keep "Device A (owner) shares a note while Device B (viewer) is offline." then change the next bullets to "When Device B later reconnects and runs pull, it receives the historical note as a backfill upsert." and "If the owner revokes later, Device B gets a delete tombstone on the next pull."), ensuring meaning is unchanged and references to Device A (owner) and Device B (viewer) remain clear.datafn/docs/content/docs/dfql/search.mdx (1)
70-70: Minor formatting improvement for clarity.The source options would be clearer with inline code formatting to match the style used elsewhere in the document.
📝 Suggested fix
-`source: auto|local|remote` controls where search executes: +`source: "auto" | "local" | "remote"` controls where search executes:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@datafn/docs/content/docs/dfql/search.mdx` at line 70, Wrap each search source option in inline code formatting where the line currently reads `source: auto|local|remote` so it matches the doc style; update the text containing that exact string to use inline code for `auto`, `local`, and `remote` (e.g., `source: `auto` | `local` | `remote``) to improve clarity and consistency with other examples.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c5e11e45-0d45-4585-8a4d-ce2058959829
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (131)
datafn/docs/.gitignoredatafn/docs/app/docs/[[...slug]]/page.tsxdatafn/docs/app/docs/layout.tsxdatafn/docs/app/global.cssdatafn/docs/app/layout.config.tsxdatafn/docs/app/layout.tsxdatafn/docs/app/not-found.tsxdatafn/docs/app/opengraph-image.tsxdatafn/docs/app/page.tsxdatafn/docs/components/ai/page-actions.tsxdatafn/docs/components/mdx/mermaid.tsxdatafn/docs/content/docs/cli/drizzle-codegen.mdxdatafn/docs/content/docs/cli/generate.mdxdatafn/docs/content/docs/cli/index.mdxdatafn/docs/content/docs/cli/meta.jsondatafn/docs/content/docs/cli/type-codegen.mdxdatafn/docs/content/docs/cli/validate.mdxdatafn/docs/content/docs/dfql/aggregations.mdxdatafn/docs/content/docs/dfql/filters.mdxdatafn/docs/content/docs/dfql/index.mdxdatafn/docs/content/docs/dfql/meta.jsondatafn/docs/content/docs/dfql/mutations.mdxdatafn/docs/content/docs/dfql/pagination.mdxdatafn/docs/content/docs/dfql/queries.mdxdatafn/docs/content/docs/dfql/schema/fields.mdxdatafn/docs/content/docs/dfql/schema/index.mdxdatafn/docs/content/docs/dfql/schema/meta.jsondatafn/docs/content/docs/dfql/schema/relations.mdxdatafn/docs/content/docs/dfql/schema/resources.mdxdatafn/docs/content/docs/dfql/schema/system-fields.mdxdatafn/docs/content/docs/dfql/search.mdxdatafn/docs/content/docs/dfql/select.mdxdatafn/docs/content/docs/dfql/sorting.mdxdatafn/docs/content/docs/dfql/transactions.mdxdatafn/docs/content/docs/documentation/advanced/change-tracking.mdxdatafn/docs/content/docs/documentation/advanced/debouncing.mdxdatafn/docs/content/docs/documentation/advanced/error-handling.mdxdatafn/docs/content/docs/documentation/advanced/guards.mdxdatafn/docs/content/docs/documentation/advanced/idempotency.mdxdatafn/docs/content/docs/documentation/advanced/meta.jsondatafn/docs/content/docs/documentation/advanced/security.mdxdatafn/docs/content/docs/documentation/client/events.mdxdatafn/docs/content/docs/documentation/client/frameworks.mdxdatafn/docs/content/docs/documentation/client/kv.mdxdatafn/docs/content/docs/documentation/client/meta.jsondatafn/docs/content/docs/documentation/client/mutations.mdxdatafn/docs/content/docs/documentation/client/queries.mdxdatafn/docs/content/docs/documentation/client/setup.mdxdatafn/docs/content/docs/documentation/client/signals.mdxdatafn/docs/content/docs/documentation/client/tables.mdxdatafn/docs/content/docs/documentation/client/transactions.mdxdatafn/docs/content/docs/documentation/concepts/capabilities.mdxdatafn/docs/content/docs/documentation/concepts/meta.jsondatafn/docs/content/docs/documentation/concepts/multi-tenancy.mdxdatafn/docs/content/docs/documentation/concepts/overview.mdxdatafn/docs/content/docs/documentation/concepts/sharing-v2.mdxdatafn/docs/content/docs/documentation/database/adapters.mdxdatafn/docs/content/docs/documentation/database/drizzle.mdxdatafn/docs/content/docs/documentation/database/meta.jsondatafn/docs/content/docs/documentation/database/transactions.mdxdatafn/docs/content/docs/documentation/index.mdxdatafn/docs/content/docs/documentation/meta.jsondatafn/docs/content/docs/documentation/migrations/meta.jsondatafn/docs/content/docs/documentation/migrations/spv2.mdxdatafn/docs/content/docs/documentation/plugins/client-search.mdxdatafn/docs/content/docs/documentation/plugins/custom-plugins.mdxdatafn/docs/content/docs/documentation/plugins/meta.jsondatafn/docs/content/docs/documentation/plugins/overview.mdxdatafn/docs/content/docs/documentation/server/authorization.mdxdatafn/docs/content/docs/documentation/server/meta.jsondatafn/docs/content/docs/documentation/server/observability.mdxdatafn/docs/content/docs/documentation/server/rate-limiting.mdxdatafn/docs/content/docs/documentation/server/rest-api.mdxdatafn/docs/content/docs/documentation/server/routes.mdxdatafn/docs/content/docs/documentation/server/setup.mdxdatafn/docs/content/docs/documentation/server/validation.mdxdatafn/docs/content/docs/documentation/server/websockets.mdxdatafn/docs/content/docs/documentation/storage/custom.mdxdatafn/docs/content/docs/documentation/storage/indexeddb.mdxdatafn/docs/content/docs/documentation/storage/memory.mdxdatafn/docs/content/docs/documentation/storage/meta.jsondatafn/docs/content/docs/documentation/storage/overview.mdxdatafn/docs/content/docs/documentation/sync/clone-up.mdxdatafn/docs/content/docs/documentation/sync/clone.mdxdatafn/docs/content/docs/documentation/sync/cross-tab.mdxdatafn/docs/content/docs/documentation/sync/hydration.mdxdatafn/docs/content/docs/documentation/sync/meta.jsondatafn/docs/content/docs/documentation/sync/offline-first.mdxdatafn/docs/content/docs/documentation/sync/overview.mdxdatafn/docs/content/docs/documentation/sync/pull-push.mdxdatafn/docs/content/docs/documentation/sync/sharing-sync-lifecycle.mdxdatafn/docs/content/docs/documentation/use-cases/meta.jsondatafn/docs/content/docs/documentation/use-cases/sharing-patterns.mdxdatafn/docs/content/docs/index.mdxdatafn/docs/content/docs/meta.jsondatafn/docs/content/docs/reference/client/config.mdxdatafn/docs/content/docs/reference/client/events.mdxdatafn/docs/content/docs/reference/client/meta.jsondatafn/docs/content/docs/reference/client/mutation.mdxdatafn/docs/content/docs/reference/client/query.mdxdatafn/docs/content/docs/reference/client/signal.mdxdatafn/docs/content/docs/reference/client/storage.mdxdatafn/docs/content/docs/reference/client/svelte.mdxdatafn/docs/content/docs/reference/client/sync.mdxdatafn/docs/content/docs/reference/client/transport.mdxdatafn/docs/content/docs/reference/core/date.mdxdatafn/docs/content/docs/reference/core/errors.mdxdatafn/docs/content/docs/reference/core/filters.mdxdatafn/docs/content/docs/reference/core/hooks.mdxdatafn/docs/content/docs/reference/core/kv.mdxdatafn/docs/content/docs/reference/core/meta.jsondatafn/docs/content/docs/reference/core/normalize.mdxdatafn/docs/content/docs/reference/core/schema.mdxdatafn/docs/content/docs/reference/core/search-provider.mdxdatafn/docs/content/docs/reference/core/types.mdxdatafn/docs/content/docs/reference/index.mdxdatafn/docs/content/docs/reference/meta.jsondatafn/docs/content/docs/reference/server/config.mdxdatafn/docs/content/docs/reference/server/execution.mdxdatafn/docs/content/docs/reference/server/meta.jsondatafn/docs/content/docs/reference/server/middleware.mdxdatafn/docs/content/docs/reference/server/routes.mdxdatafn/docs/content/docs/reference/server/websocket.mdxdatafn/docs/lib/source.tsdatafn/docs/next.config.mjsdatafn/docs/package.jsondatafn/docs/postcss.config.mjsdatafn/docs/source.config.tsdatafn/docs/tsconfig.jsondatafn/docs/vercel.jsonpackage.json
| import "./global.css"; | ||
| import "@21n/fonts/styles.css"; | ||
| import { RootProvider } from "fumadocs-ui/provider"; | ||
| import { DocsRootLayout } from "@superfunctions/docs-theme"; |
There was a problem hiding this comment.
This import is currently a hard build failure.
datafn/docs still cannot build on this branch because @superfunctions/docs-theme resolves to workspace source that references missing ./layout.js and ./config.js. Please fix the package export/entrypoint setup before merging.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@datafn/docs/app/layout.tsx` at line 4, The import of DocsRootLayout from
"@superfunctions/docs-theme" fails because the package resolves to workspace
source that lacks built entry files (./layout.js and ./config.js); fix the
package export/entrypoint by either (A) updating the
"@superfunctions/docs-theme" package.json "main"/"exports" to point at the built
artifacts (e.g., dist or lib files) and ensure those files are produced by the
build, or (B) change consumers to import from the package's built entry (e.g.,
"@superfunctions/docs-theme/dist" or the appropriate built path); locate
references to DocsRootLayout in datafn/docs/app/layout.tsx and update the
package's package.json build scripts to emit layout.js and config.js so the
import resolves without referencing workspace source.
| try { | ||
| await navigator.clipboard.write([ | ||
| new ClipboardItem({ | ||
| 'text/plain': fetch(markdownUrl).then(async (res) => { | ||
| const content = await res.text(); | ||
| cache.set(markdownUrl, content); | ||
|
|
||
| return content; | ||
| }), | ||
| }), | ||
| ]); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Where markdownUrl is constructed and consumed:"
rg -n -C3 'markdownUrl|page\.url.*\.mdx' datafn/docs
echo
echo "Routes that could serve raw markdown:"
fd -i 'route\.(ts|tsx|js|jsx)$' datafn/docs/app -x rg -n -C2 'mdx|markdown|text/plain|content/docs|raw' {} || true
echo
if [ -d datafn/docs/public ]; then
echo "Public markdown assets:"
fd -i '\.(md|mdx)$' datafn/docs/public || true
else
echo "datafn/docs/public does not exist"
fiRepository: 21nCo/super-functions
Length of output: 4363
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== All route-like files in datafn/docs ==="
fd -e ts -e tsx -e js -e jsx 'route\.' datafn/docs --hidden | head -20
echo
echo "=== All API or middleware handlers ==="
fd -path '*api*' -o -path '*middleware*' datafn/docs --type f | grep -E '\.(ts|tsx|js|jsx)$' || echo "None found"
echo
echo "=== Check for catch-all routes ==="
rg -n '\[\[.*slug.*\]\]|catch.*all' datafn/docs/app --type ts --type tsx || echo "No catch-all patterns found"
echo
echo "=== Build/export scripts that might generate assets ==="
fd -e json datafn/docs/package.json -x cat {} | grep -A 20 '"scripts"' || true
echo
echo "=== Check next.config for rewrites/redirects ==="
fd -i 'next.config' datafn/docs -x cat {} || echo "No next.config found"Repository: 21nCo/super-functions
Length of output: 741
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== page.tsx full file to understand page object ==="
cat -n datafn/docs/app/docs/\[\[..slug\]\]/page.tsx | head -80
echo
echo "=== Look for where 'data' comes from ==="
rg -n 'getPage\|getSourceData\|docs\.getPage' datafn/docs/app --max-count 20
echo
echo "=== Search for fumadocs source configuration ==="
rg -n 'source\|createMDX\|docs' datafn/docs/app --max-count 20 -B2 -A2
echo
echo "=== Check app initialization files ==="
find datafn/docs/app -maxdepth 2 -name 'layout.*' -o -name 'route.*' -o -name 'source.*' | xargs ls -la 2>/dev/null || trueRepository: 21nCo/super-functions
Length of output: 209
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Find the actual page.tsx file ==="
fd -i 'page.tsx' datafn/docs/app
echo
echo "=== List the directory structure of datafn/docs/app/docs ==="
find datafn/docs/app/docs -type f -name '*.tsx' -o -name '*.ts' 2>/dev/null | head -20
echo
echo "=== Full content of the docs page file ==="
find datafn/docs/app/docs -name 'page.tsx' -exec cat -n {} \;
echo
echo "=== Search for fumadocs source setup ==="
rg -n 'source\|createMDX\|getPage' datafn/docs --max-count 30
echo
echo "=== Check for lib or utils that configure docs ==="
find datafn/docs -path '*/lib/*' -o -path '*/utils/*' -name '*.ts' -o -name '*.tsx' | head -20Repository: 21nCo/super-functions
Length of output: 3471
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Find lib/source file ==="
find datafn/docs -path '*/lib/source*' -type f
echo
echo "=== Read the source configuration ==="
find datafn/docs -path '*/lib/source*' -type f -exec cat -n {} \;
echo
echo "=== Check if there's a source config in root ==="
find datafn/docs -maxdepth 3 -name 'source.ts' -o -name 'source.tsx' | xargs cat -n 2>/dev/null || trueRepository: 21nCo/super-functions
Length of output: 856
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Find .source configuration ==="
find datafn/docs -name '.source*' -type f 2>/dev/null | head -10
echo
echo "=== Search for where `@/.source` is generated or configured ==="
rg -n '\.source\|fumadocs' datafn/docs --max-count 30
echo
echo "=== Check for API routes or route handlers for markdown ==="
fd -path '*/app/api/*' -name 'route.*' datafn/docs -x cat -n {} \; 2>/dev/null || echo "No API routes found"
echo
echo "=== Look for any middleware or public routing ==="
find datafn/docs -name 'middleware.*' -o -name 'next.config.*' | xargs cat -n 2>/dev/null || true
echo
echo "=== Search for fumadocs-mdx usage and what files it exposes ==="
rg -n 'fumadocs' datafn/docs/next.config.* -A 10Repository: 21nCo/super-functions
Length of output: 162
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Full content of next.config.js/mjs/ts ==="
find datafn/docs -maxdepth 1 -name 'next.config.*' -exec cat -n {} \;
echo
echo "=== Search for any .mdx file routing or API ==="
rg -n '\.mdx|/api/|fetch' datafn/docs/app --max-count 40
echo
echo "=== Check what page.url typically contains by looking at fumadocs types ==="
rg -n 'page\.url' datafn/docs -B5 -A5
echo
echo "=== Look for build outputs or dist directories ==="
find datafn/docs -maxdepth 2 -type d \( -name dist -o -name .next -o -name build -o -name out \) 2>/dev/null
echo
echo "=== Check package.json to understand fumadocs version and setup ==="
cat -n datafn/docs/package.json | grep -A 50 '"dependencies"' | head -60Repository: 21nCo/super-functions
Length of output: 2801
🏁 Script executed:
#!/bin/bash
set -euo pipefmp
echo "=== Search fumadocs core or mdx for raw file serving ==="
rg -n 'raw|getRaw|file' datafn/docs --max-count 20
echo
echo "=== Check if fumadocs provides a built-in route for raw content ==="
rg -n 'source\.' datafn/docs/lib/source.ts -A 20
echo
echo "=== Look for actual content/docs files ==="
find datafn/docs -path '*/content/docs/*' -type f 2>/dev/null | head -10
echo
echo "=== Check if fumadocs-mdx generates anything special ==="
find datafn/docs -maxdepth 1 -type f -name '.source*' -o -name 'source*' 2>/dev/null
echo
echo "=== Try searching for any raw content API or handler ==="
rg -n 'getRawFile\|getFile\|raw\|text/plain' datafn/docs -B3 -A3 --max-count 30Repository: 21nCo/super-functions
Length of output: 117
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Search fumadocs core or mdx for raw file serving ==="
rg -n 'raw|getRaw|file' datafn/docs --max-count 20
echo
echo "=== Check if fumadocs provides a built-in route for raw content ==="
rg -n 'source\.' datafn/docs/lib/source.ts -A 20
echo
echo "=== Look for actual content/docs files ==="
find datafn/docs -path '*/content/docs/*' -type f 2>/dev/null | head -10
echo
echo "=== Check if fumadocs-mdx generates anything special ==="
find datafn/docs -maxdepth 1 -type f \( -name '.source*' -o -name 'source*' \) 2>/dev/null
echo
echo "=== Try searching for any raw content API or handler ==="
rg -n 'getRawFile\|getFile\|raw\|text/plain' datafn/docs -B3 -A3 --max-count 30Repository: 21nCo/super-functions
Length of output: 5213
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== List content/docs structure ==="
find datafn/docs/content/docs -type f -name '*.mdx' 2>/dev/null | head -20
echo
echo "=== Check fumadocs-core source patterns and what page object contains ==="
rg -n 'getPage\|page\.url\|page\.path' datafn/docs -B2 -A2 | head -80
echo
echo "=== Look for any static file serving or public routes ==="
find datafn/docs/public -type f 2>/dev/null || echo "No public directory"
echo
echo "=== Check if there's an API route that might serve markdown ==="
find datafn/docs/app -name '*route*' -o -name '*api*' 2>/dev/null | xargs ls -la 2>/dev/null || echo "No API routes"
echo
echo "=== Check fumadocs documentation in node_modules or inline comments ==="
rg -n 'getRaw\|getSourceMap\|serveRaw' datafn/docs || echo "No raw serving methods found"Repository: 21nCo/super-functions
Length of output: 1003
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Check fumadocs documentation for raw content serving ==="
rg -n 'getRaw\|getSourceMap\|raw.*url\|source\.files' datafn/docs/lib datafn/docs/app -B3 -A3
echo
echo "=== Look at page-actions to see how markdownUrl is actually used ==="
cat -n datafn/docs/components/ai/page-actions.tsx | sed -n '20,100p'
echo
echo "=== Check what fumadocs source object actually provides ==="
rg -n 'loader\|baseUrl\|source\(' datafn/docs/lib/source.ts -B5 -A10Repository: 21nCo/super-functions
Length of output: 125
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== Full page-actions.tsx file ==="
cat -n datafn/docs/components/ai/page-actions.tsx
echo
echo "=== Check if markdownUrl is ever successfully fetched ==="
rg -n 'fetch.*markdownUrl\|markdownUrl.*fetch' datafn/docs -B2 -A5Repository: 21nCo/super-functions
Length of output: 12924
Add a route handler to serve raw markdown content.
This component assumes markdownUrl points to a fetchable raw MDX endpoint. The current code constructs it as ${page.url}.mdx (e.g., /docs/cli/generate.mdx), but Next.js does not automatically serve raw .mdx files from those paths. The fetch(markdownUrl) call on line 29 and the "View as Markdown" link on line 91 will both return 404.
Either create an API route that exposes the raw markdown content at those URLs, or pass a valid endpoint to markdownUrl from the page component.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@datafn/docs/components/ai/page-actions.tsx` around lines 26 - 36, The
component is fetching raw MDX from markdownUrl (used in fetch(markdownUrl) and
navigator.clipboard.write) and the "View as Markdown" link but Next.js won't
serve .mdx at that path; either implement an API route that reads the source
MDX/markdown and returns it at the markdownUrl endpoint (so fetch(markdownUrl)
and the "View as Markdown" link succeed), or change the page component to pass a
valid raw-markdown endpoint into the markdownUrl prop; update references to
markdownUrl, fetch(markdownUrl), and the "View as Markdown" link target
accordingly so they point to the new API route or valid URL.
| mermaid.initialize({ | ||
| startOnLoad: false, | ||
| securityLevel: 'loose', | ||
| fontFamily: 'inherit', | ||
| themeCSS: 'margin: 1.5rem auto 0;', | ||
| theme: resolvedTheme === 'dark' ? 'dark' : 'default', | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For Mermaid 11.12.3, what protections are disabled by securityLevel: "loose"compared withstrict, and is strict the default security level?
💡 Result:
For Mermaid 11.12.3, setting securityLevel to "loose" disables two key protections compared to "strict": - Encoding of HTML tags in diagram text (they are allowed unencoded in "loose"). - Disabling of click functionality (clicks are enabled in "loose", allowing interactive event bindings like the click directive). "strict" is the default security level.
Citations:
- 1: https://mermaid.js.org/config/schema-docs/config-properties-securitylevel.html
- 2: GHSA-wvh5-6vjm-23qh
- 3: https://fossies.org/linux/www/mermaid-mermaid-11.12.3.tar.gz/mermaid-mermaid-11.12.3/packages/mermaid/src/utils.spec.ts
- 4: https://mermaid.ai/open-source/config/setup/mermaid/interfaces/MermaidConfig.html
- 5: https://mermaid.ai/open-source/config/schema-docs/config-properties-securitylevel.html
Change securityLevel from 'loose' to 'strict'.
Setting securityLevel: 'loose' allows unencoded HTML tags in diagram text and enables click event bindings. Combined with dangerouslySetInnerHTML, this creates an XSS vulnerability if diagrams are ever sourced from untrusted input. Since 'strict' is the default and provides the necessary protections here, use it instead.
Diff
mermaid.initialize({
startOnLoad: false,
- securityLevel: 'loose',
+ securityLevel: 'strict',
fontFamily: 'inherit',
themeCSS: 'margin: 1.5rem auto 0;',
theme: resolvedTheme === 'dark' ? 'dark' : 'default',
});Also applies to: lines 48-53
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@datafn/docs/components/mdx/mermaid.tsx` around lines 33 - 39, Update the
mermaid.initialize configuration to use a safe security level: locate the
mermaid.initialize(...) calls (the initialization block in mermaid.tsx) and
change securityLevel from 'loose' to 'strict' in both places (the block that
sets startOnLoad, fontFamily, themeCSS, theme, etc.), ensuring you keep the rest
of the options intact; this prevents unencoded HTML and click bindings when
diagrams are rendered (important because the component uses
dangerouslySetInnerHTML).
| source: { | ||
| files: (fumadocsSource as any).files(), | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check fumadocs-core version and types
echo "=== Checking fumadocs versions in package.json ==="
cat datafn/docs/package.json | jq '.dependencies, .devDependencies' 2>/dev/null | grep -i fumadocs || echo "fumadocs not found in package.json"
echo ""
echo "=== Searching for toFumadocsSource usage patterns ==="
rg -n "toFumadocsSource" --type ts -C 3
echo ""
echo "=== Checking source.config.ts for docs definition ==="
fd -t f "source.config" --exec cat {}Repository: 21nCo/super-functions
Length of output: 960
🏁 Script executed:
#!/bin/bash
# Read the complete source.ts file
echo "=== Complete source.ts file ==="
cat datafn/docs/lib/source.ts
echo ""
echo "=== Check node_modules for fumadocs types (if available) ==="
find . -name "*.d.ts" -path "*/fumadocs-core/*" | head -20
echo ""
echo "=== Search for other loader() usage patterns ==="
rg -n "loader\(" --type ts -A 5 | head -40
echo ""
echo "=== Check if there are type errors in the project ==="
fd -t f "tsconfig.json" --exec cat {}Repository: 21nCo/super-functions
Length of output: 15133
🌐 Web query:
fumadocs-core v15 loader source files API configuration
💡 Result:
In fumadocs-core v15 (latest ~15.8.x as of late 2025, with docs current as of 2026), the primary "loader" refers to the loader function from 'fumadocs-core/source', a server-side API that processes content sources (e.g., MDX files from fumadocs-mdx or content-collections) into a unified Fumadocs source interface. It generates page slugs, URLs, page trees, and supports i18n, plugins, and multiple sources. Source files are virtual/in-memory representations passed from content sources (no direct filesystem access in loader). ### Key API and Configuration (from official docs) Import: import { loader } from 'fumadocs-core/source'; Basic usage with fumadocs-mdx/content-collections: import { docs } from 'collections/server'; // Generated .source/collections export const source = loader({ source: docs.toFumadocsSource, baseUrl: '/docs', // Required: base path for URLs }); Full options object: - source: Required Source object (from .toFumadocsSource, custom Source {files: File[]}, or multiple({docs: ..., blog: ...})). - baseUrl: string - Base URL path. - url?: (slugs: string[], locale?: string) => string - Custom URL generator. - slugs?: (file: File) => string[] - Custom slug generator from file path/data. - i18n?: I18nConfig - For multi-language page trees (with fallbackLanguage). - plugins?: LoaderPlugin[] or ((ctx) => LoaderPlugin[]) - Extend processing (e.g., lucideIconsPlugin for icons). ### Output Methods (on returned source) - getPage(slugs: string[], locale?: string): Page data (body, toc, structuredData). - getPages(locale?: string): All pages list. - getPageTree(locale?: string): Hierarchical page tree. - getNodePage(node) / getNodeMeta(node): From tree nodes. - params: For Next.js generateStaticParams. - Client serialization: serializePageTree, with useFumadocsLoader hook. ### Integration with fumadocs-mdx Loader (Next.js Webpack Loader) fumadocs-mdx uses a separate Next.js loader via createMDX in next.config.mjs to process MDX files into .source/ collections: import { createMDX } from 'fumadocs-mdx/next'; const withMDX = createMDX({ configPath: './my-config.ts', // Optional: Custom config file path (default inferred). }); export default withMDX(nextConfig); - Runs file watcher in dev (next dev) to regenerate .source/. - Config defined in source.config.ts (or similar): defineDocs({dir: 'content/docs'}), global/mdxOptions. No major v15-specific changes to loader API (v15 focused on Tailwind v4 support). Source code: https://github.com/fuma-nama/fumadocs/tree/main/packages/fumadocs-core/src/source (inferred from docs/raw links). Examples: Official docs at https://www.fumadocs.dev/docs/headless/source-api.
Citations:
- 1: https://www.fumadocs.dev/docs/headless/source-api
- 2: https://www.fumadocs.dev/docs/headless/source-api/source
- 3: https://fumadocs.dev/docs/mdx/plugin
- 4: https://www.fumadocs.dev/docs/headless/source-api/plugins
- 5: https://www.fumadocs.dev/docs/headless/content-collections
- 6: https://fumadocs.vercel.app/docs/mdx/next
- 7: https://www.fumadocs.dev/docs/manual-installation/next
Remove incorrect API usage and as any cast.
The source parameter should receive the result of docs.toFumadocsSource() directly, not wrapped in a {files: ...} object. According to the fumadocs-core v15 API, the loader() function expects a Source object, and toFumadocsSource() already returns a compatible type.
Replace lines 8-10 with:
source: fumadocsSource,
Or simplify to:
source: docs.toFumadocsSource(),
The as any cast masks incorrect API usage rather than a type safety issue.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@datafn/docs/lib/source.ts` around lines 8 - 10, The code is incorrectly
wrapping fumadocsSource in an object and using an `as any` cast; replace the
`source: { files: (fumadocsSource as any).files() }` usage with a direct Source
value by setting `source` to `fumadocsSource` or calling
`docs.toFumadocsSource()` (e.g., `source: docs.toFumadocsSource()`), removing
the `{ files: ... }` wrapper and the `as any` cast so the value matches the
fumadocs-core v15 Source API expected by `loader()`.
datafn/docs/tsconfig.json
Outdated
| "@superfunctions/docs-theme": [ | ||
| "../../packages/docs-theme/src/index.ts" | ||
| ], | ||
| "@superfunctions/docs-theme/tokens.css": [ | ||
| "../../packages/docs-theme/src/tokens.css" | ||
| ], |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the docs-theme package.json for main/exports fields and verify build output location
echo "=== Checking docs-theme package.json for output configuration ==="
cat ../../packages/docs-theme/package.json | jq -r '.main, .exports, .scripts.build'
echo -e "\n=== Checking for build output directories ==="
fd -t d -d 1 'dist|lib|build' ../../packages/docs-theme/
echo -e "\n=== Checking if layout.js and config.js exist in source vs build ==="
fd 'layout\.js|config\.js' ../../packages/docs-theme/Repository: 21nCo/super-functions
Length of output: 563
🏁 Script executed:
#!/bin/bash
# First, understand the repository structure
echo "=== Repository structure ==="
git ls-files | grep -E 'package\.json|tsconfig\.json' | head -20
echo -e "\n=== Check if datafn/docs exists ==="
ls -la datafn/docs/ 2>/dev/null || echo "datafn/docs not found"
echo -e "\n=== Check if there are packages directories ==="
find . -maxdepth 3 -type d -name "packages" 2>/dev/null
echo -e "\n=== List all directories at depth 2 ==="
ls -laRepository: 21nCo/super-functions
Length of output: 2785
🏁 Script executed:
#!/bin/bash
echo "=== Contents of packages directory ==="
ls -la packages/
echo -e "\n=== Check for docs-theme package ==="
find packages -maxdepth 1 -type d -name "*docs*" -o -name "*theme*"
echo -e "\n=== List all packages ==="
ls packages/Repository: 21nCo/super-functions
Length of output: 1261
🏁 Script executed:
#!/bin/bash
echo "=== docs-theme package.json ==="
cat packages/docs-theme/package.json
echo -e "\n=== docs-theme directory structure ==="
find packages/docs-theme -type f -o -type d | head -30
echo -e "\n=== Search for layout.js and config.js ==="
find packages/docs-theme -name "layout.js" -o -name "config.js"
echo -e "\n=== Check what output directories exist ==="
ls -la packages/docs-theme/Repository: 21nCo/super-functions
Length of output: 1750
Path alias points to TypeScript source files instead of the built JavaScript distribution.
The PR objectives state that Next.js "fails to resolve ./layout.js and ./config.js" when resolving @superfunctions/docs-theme. The root cause is that the path aliases in datafn/docs/tsconfig.json point directly to TypeScript source files instead of the built distribution.
The packages/docs-theme/package.json explicitly configures the package output:
"main": "./dist/index.js",
"exports": {
".": "./dist/index.js",
"./tokens.css": "./dist/tokens.css"
}However, the path aliases point to source files:
"@superfunctions/docs-theme": ["../../packages/docs-theme/src/index.ts"]
"@superfunctions/docs-theme/tokens.css": ["../../packages/docs-theme/src/tokens.css"]Next.js requires the JavaScript distribution output, not TypeScript source files. Update the path aliases to point to the dist directory where the build output is located:
🔧 Proposed fix
"paths": {
"@/*": [
"./*"
],
"@superfunctions/docs-theme": [
- "../../packages/docs-theme/src/index.ts"
+ "../../packages/docs-theme/dist/index.js"
],
"@superfunctions/docs-theme/tokens.css": [
- "../../packages/docs-theme/src/tokens.css"
+ "../../packages/docs-theme/dist/tokens.css"
],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@datafn/docs/tsconfig.json` around lines 29 - 34, The tsconfig path aliases
"@superfunctions/docs-theme" and "@superfunctions/docs-theme/tokens.css"
currently point to TypeScript source files; change them to point to the built
JS/CSS distribution instead (use the package's dist outputs, e.g., replace
"../../packages/docs-theme/src/index.ts" with
"../../packages/docs-theme/dist/index.js" and
"../../packages/docs-theme/src/tokens.css" with
"../../packages/docs-theme/dist/tokens.css") so Next.js resolves the compiled
layout/config files correctly.
|
@codex Review this PR |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0d69586709
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| editOnGithub={{ | ||
| owner: gitConfig.user, | ||
| repo: gitConfig.repo, | ||
| path: `datafn/docs/app/docs/${page.path}`, |
There was a problem hiding this comment.
Point edit-on-GitHub links at docs content files
The editOnGithub.path currently points to datafn/docs/app/docs/${page.path}, but the MDX sources for these pages live under datafn/docs/content/docs/. This makes the “Edit on GitHub” action resolve to non-existent files for every docs page, while the adjacent ViewOptions link already uses the correct content/docs prefix. Updating this path is necessary for edit links to work.
Useful? React with 👍 / 👎.
| <LLMCopyButton markdownUrl={`${page.url}.mdx`} /> | ||
| <ViewOptions | ||
| markdownUrl={`${page.url}.mdx`} |
There was a problem hiding this comment.
Serve markdown before wiring page actions to
*.mdx URLs
These actions assume ${page.url}.mdx returns raw Markdown, but this commit does not add the required *.mdx route handler/rewrite (and datafn/docs/next.config.mjs has no rewrite for /docs/:path*.mdx). As a result, “Copy Markdown” / “View as Markdown” will fetch the wrong payload (typically 404/HTML) instead of page markdown across all docs pages.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
3 issues found across 15 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="datafn/docs/app/global.css">
<violation number="1" location="datafn/docs/app/global.css:6">
P1: This import resolves to `@superfunctions/docs-theme`’s exported `./dist/tokens.css`, but that CSS file is not present in the repo/build inputs, so the stylesheet import will fail to resolve.</violation>
</file>
<file name="datafn/docs/content/docs/reference/client/svelte.mdx">
<violation number="1" location="datafn/docs/content/docs/reference/client/svelte.mdx:62">
P3: The docs now contradict themselves: `data` is typed as `T | undefined` in the type definition, but the properties table still says `T`.</violation>
</file>
<file name="datafn/docs/app/api/docs/raw/[...slug]/route.ts">
<violation number="1" location="datafn/docs/app/api/docs/raw/[...slug]/route.ts:13">
P1: The route builds a filesystem path from URL segments without verifying the resolved path stays inside `content/docs`, which can allow directory traversal file reads.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| @import "fumadocs-ui/css/preset.css"; | ||
|
|
||
| /* Shared theme package source: @superfunctions/docs-theme/tokens.css */ | ||
| @import "@superfunctions/docs-theme/tokens.css"; |
There was a problem hiding this comment.
P1: This import resolves to @superfunctions/docs-theme’s exported ./dist/tokens.css, but that CSS file is not present in the repo/build inputs, so the stylesheet import will fail to resolve.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At datafn/docs/app/global.css, line 6:
<comment>This import resolves to `@superfunctions/docs-theme`’s exported `./dist/tokens.css`, but that CSS file is not present in the repo/build inputs, so the stylesheet import will fail to resolve.</comment>
<file context>
@@ -3,4 +3,4 @@
/* Shared theme package source: @superfunctions/docs-theme/tokens.css */
-@import "../../../packages/docs-theme/src/tokens.css";
+@import "@superfunctions/docs-theme/tokens.css";
</file context>
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="datafn/docs/app/api/docs/raw/[...slug]/route.ts">
<violation number="1" location="datafn/docs/app/api/docs/raw/[...slug]/route.ts:16">
P1: The traversal guard is incomplete: `relativePath.startsWith("..")` does not block absolute `relativePath` values (e.g. Windows cross-drive paths), so out-of-root files can still be read.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Merge activity
|
## Summary - add the `datafn/docs` site from `next` - wire the root workspace and lockfile for the docs slice - include documentation content for DFQL, client/server usage, sync, storage, migrations, and CLI docs ## Validation - `cd packages/docs-theme && npm run build` - `cd datafn/docs && npm run build` is currently blocked because Next resolves `@superfunctions/docs-theme` to workspace source files and then fails to resolve `./layout.js` / `./config.js` from that source path in this branch shape <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Adds `datafn/docs`, a Next.js docs site using `fumadocs-ui` and `@superfunctions/docs-theme`, with comprehensive DataFn docs (DFQL, client/server, sync, storage, migrations, CLI). Satisfies SF-7; review fixes include stricter raw MD/MDX endpoint validation and importing shared theme tokens. - **New Features** - New docs app at `datafn/docs` with `app/` routes, global styles (imports `@superfunctions/docs-theme/tokens.css`), OG image, 404, root redirect, and footer attribution. - Integrates theme via `createBaseLayoutOptions`/`DocsRootLayout`; GitHub edit links point to `21nCo/super-functions@dev`. - LLM copy button powered by `/api/docs/raw/[...slug]` (safe slug and path checks); Mermaid MDX component. - **Migration** - Build steps: `cd packages/docs-theme && npm run build`; then `cd datafn/docs && npm run build`. - Current blocker: Next resolves `@superfunctions/docs-theme` to workspace source and can’t find built entrypoints; use a published/packed package or update resolution to built outputs until aliasing is fixed. <sup>Written for commit 450b321. Summary will update on new commits.</sup> <!-- End of auto-generated description by cubic. --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Launched comprehensive documentation site with guides for client and server setup, DFQL query language reference, and CLI tools * Added detailed API reference for `@datafn/core`, `@datafn/client`, and `@datafn/server` packages * Documented advanced topics including offline-first sync, capabilities, multi-tenancy, sharing patterns, guards, idempotency, and error handling * Included database and storage adapter guides, use cases, and security best practices <!-- end of auto-generated comment: release notes by coderabbit.ai -->
450b321 to
05f2b61
Compare
Summary
datafn/docssite fromnextValidation
cd packages/docs-theme && npm run buildcd datafn/docs && npm run buildis currently blocked because Next resolves@superfunctions/docs-themeto workspace source files and then fails to resolve./layout.js/./config.jsfrom that source path in this branch shapeSummary by cubic
Adds
datafn/docs, a Next.js docs site usingfumadocs-uiand@superfunctions/docs-theme, delivering comprehensive DataFn docs (DFQL, client/server, sync, storage, migrations, CLI). Satisfies SF-7.New Features
datafn/docswithapp/routes, global styles (imports@superfunctions/docs-theme/tokens.css), OG image, 404, root redirect, and footer attribution.createBaseLayoutOptions/DocsRootLayout; GitHub edit links point to21nCo/super-functions@dev./api/docs/raw/[...slug](strict slug and path traversal checks); Mermaid MDX component.Migration
cd packages/docs-theme && npm run build; thencd datafn/docs && npm run build.@superfunctions/docs-themeto workspace source and can’t find built entrypoints; use a published/packed package or update resolution to built outputs until aliasing is fixed.Written for commit 05f2b61. Summary will update on new commits.
Summary by CodeRabbit