Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughConsolidates configuration and contexts into a single page, adds a CLI reference and extensive programmatic API MDX pages, expands and relaxes many schema docs and examples, introduces a TypeScript reference generator script, and updates internal doc links and examples. Changes
Sequence Diagram(s)sequenceDiagram
participant Gen as Reference Generator (scripts/generate-references.ts)
participant Schemas as schemas.json
participant TS as TypeScript sources
participant FS as Filesystem
Gen->>Schemas: read schema components
Gen->>Gen: build PageDefs & cross-reference map
Gen->>TS: parse TS sources for exported API signatures
Gen->>Gen: merge parsed API signatures with PageDefs
Gen->>FS: write schema MD/MDX pages under fern/pages/reference/schemas
Gen->>FS: write API MDX pages under fern/pages/reference/api (preserve custom blocks)
FS-->>Gen: confirm writes
Note over Gen,FS: Generation complete (schema + API pages)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR merges documentation sources, adding initial documentation structure and content for the Doc Detective documentation site. It introduces a code generation script that reads JSON schemas and TypeScript source files from the doc-detective repository to auto-generate reference documentation pages.
Changes:
- Adds
scripts/generate-references.ts: a script that generates schema reference pages (.md) and programmatic API pages (.mdx) from JSON schemas and TypeScript source files - Adds new documentation pages: programmatic API reference (
overview.mdx,run-tests.mdx,detect-tests.mdx, etc.), a consolidated configuration page (configuration.mdx), a CLI reference page, and extensive examples across many existing schema pages - Removes the old standalone
contexts.mdpage and replaces it with a#contextsanchor in the newconfiguration.mdx; updates cross-links throughout the docs
Reviewed changes
Copilot reviewed 68 out of 69 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
scripts/generate-references.ts |
New code generator script for schema and API reference pages |
package.json / package-lock.json |
Adds typescript and tsx as devDependencies for the generator script |
fern/docs.yml |
Adds API reference pages and replaces contexts.md with configuration.mdx in navigation |
fern/pages/docs/config/configuration.mdx |
New consolidated configuration page (replaces contexts.md) |
fern/pages/docs/config/contexts.md |
File deleted; content merged into configuration.mdx |
fern/pages/docs/get-started/cli-reference.mdx |
New CLI reference page |
fern/pages/docs/get-started/installation.mdx |
Adds troubleshooting and project structure sections |
fern/pages/docs/tests/overview.mdx |
Adds common test patterns and best practices sections |
fern/pages/docs/tests/inline.mdx |
Adds sections on combining tests, media recording, and troubleshooting |
fern/pages/reference/api/*.mdx |
New programmatic API reference pages for all exported functions |
fern/pages/reference/schemas/*.md |
Updated schema pages with examples, new fields, and cross-reference fixes |
fern/pages/reference/glossary.mdx / template files |
URL updates: /docs/configuration/contexts → /docs/configuration#contexts |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
fern/pages/reference/schemas/type.md
Outdated
| @@ -1,12 +1,13 @@ | |||
| --- | |||
| title: "type" | |||
| title: "typeKeys" | |||
There was a problem hiding this comment.
The frontmatter title was changed from "type" to "typeKeys", but the action wrapper field is named type in the JSON schema (the step object uses { "type": ... }). The page title should match the actual field name to avoid confusion. The cross-reference in type-keys-detailed.md line 8 already updated to [typeKeys] which is now inconsistent with how users write the step in their tests. The field is type, not typeKeys.
| ### API CRUD operations | ||
|
|
||
| ```json | ||
| { | ||
| "tests": [ | ||
| { | ||
| "description": "Test API endpoints", | ||
| "steps": [ | ||
| { | ||
| "httpRequest": { | ||
| "url": "https://api.example.com/items", | ||
| "method": "POST", | ||
| "request": { | ||
| "headers": { "Content-Type": "application/json" }, | ||
| "body": { "name": "Test item" } | ||
| }, | ||
| "response": { | ||
| "statusCode": 201 | ||
| } | ||
| } | ||
| }, | ||
| { | ||
| "httpRequest": { | ||
| "url": "https://api.example.com/items", | ||
| "method": "GET", | ||
| "response": { | ||
| "statusCode": 200 | ||
| } | ||
| } | ||
| } | ||
| ] | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
The "API CRUD operations" example uses "statusCode": 201 and "statusCode": 200 (singular) as properties inside the response object. However, per the response.md schema, the response object accepts headers, body, and required fields - there is no statusCode property. The correct way to check status codes in httpRequest is to use the top-level statusCodes array (e.g., "statusCodes": [201]), not a response.statusCode property. This example would silently not validate the status code as intended.
| ### Working with variables | ||
|
|
||
| Load environment variables and use them across steps: | ||
|
|
||
| ```json | ||
| { | ||
| "tests": [ | ||
| { | ||
| "description": "Test with variables", | ||
| "steps": [ | ||
| { "loadVariables": ".env" }, | ||
| { "goTo": "$SITE_URL" }, | ||
| { | ||
| "httpRequest": { | ||
| "url": "$API_URL/status", | ||
| "method": "GET", | ||
| "request": { | ||
| "headers": { | ||
| "Authorization": "Bearer $API_TOKEN" | ||
| } | ||
| }, | ||
| "response": { | ||
| "statusCode": 200 | ||
| } | ||
| } | ||
| } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
The "Working with variables" example also uses "statusCode": 200 (singular) in response, which is incorrect for the same reason as above. The correct field is the top-level statusCodes array.
|
|
||
| ```javascript | ||
| async resolveTests(config, detectedTests) → any | ||
| ``` | ||
|
|
||
| ## Parameters | ||
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|-------------| | ||
| | `config` | any | Yes | | | ||
| | `detectedTests` | any[] | Yes | | |
There was a problem hiding this comment.
The resolveTests() signature shows async resolveTests(config, detectedTests) → any with two positional parameters, but all code examples in the same file call it as await resolveTests({ config, detectedTests }) - a single object argument. This inconsistency between the signature block and examples will confuse developers trying to use the API.
|
|
||
| ```javascript | ||
| async resolvePaths(config, object, filePath, nested?, objectType?) → any | ||
| ``` | ||
|
|
||
| ## Parameters | ||
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|-------------| | ||
| | `config` | any | Yes | | | ||
| | `object` | any | Yes | | | ||
| | `filePath` | string | Yes | | | ||
| | `nested` | boolean | No | | | ||
| | `objectType` | string | No | | |
There was a problem hiding this comment.
The resolvePaths() signature shows async resolvePaths(config, object, filePath, nested?, objectType?) → any with positional parameters, but all code examples call it with a single object argument: await resolvePaths({ config, object, filePath, objectType }). This is the same mismatch as in detect-tests.mdx and resolve-tests.mdx. The root cause is in scripts/generate-references.ts line 1227-1229: the signature line is built from the (potentially destructured) params array, so if the actual source function uses a single destructured object parameter, the generated signature incorrectly spreads those as positional parameters.
| // Walk nested properties for titles | ||
| for (const pd of buildPageDefs()) { | ||
| if (pd.schema.properties) { | ||
| for (const prop of Object.values(pd.schema.properties)) { | ||
| registerNestedTitles(prop); | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
The registerExtraComponentTitles() function calls buildPageDefs() a second time (line 1355), which fully rebuilds all page definitions including calling get() and comp() helper functions that throw on missing schemas. This means the schema file is parsed and all page definitions are built twice for every run of the script, which is wasteful. More importantly, errors thrown by get() or comp() would be surfaced a second time during what is ostensibly a registration step. The pageDefs result from main() (line 1279) should be passed to registerExtraComponentTitles instead of calling buildPageDefs() again.
| regex | one of:<br/>- string<br/>- array of string | Optional. Regular expressions to match the markup type. | | ||
| batchMatches | boolean | Optional. If `true`, all matches are combined into a single string. | `false` | ||
| actions | one of:<br/>- string<br/>- array of one of: string, object(step) | Optional. Actions to perform when the markup type is detected. | | ||
| actions | one of:<br/>- string<br/>- array of one of:<br/>- string<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common))<br/>- object([Common](/reference/schemas/common)) | Optional. Actions to perform when the markup type is detected. | |
There was a problem hiding this comment.
The actions field in markup-definition.md renders 16 duplicate object([Common](/reference/schemas/common)) entries in the type column. This is a bug in the generator's renderType function - when the step variants all resolve to the same "Common" title (each action step shares the same common component), they are each individually rendered rather than being deduplicated or mapped to their specific action types. The rendered documentation is misleading and unhelpful to readers who need to understand what concrete action objects are valid.
|
|
||
| ```javascript | ||
| async detectTests(config) → any | ||
| ``` | ||
|
|
||
| ## Parameters | ||
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|-------------| | ||
| | `config` | any | Yes | | |
There was a problem hiding this comment.
The detectTests() signature in the generated page shows async detectTests(config) → any with a positional parameter, but all code examples in the same file (and in other API pages) call it as await detectTests({ config }) using an object argument. The signature and parameter table are inconsistent with the usage examples. The same issue applies to resolveTests() in resolve-tests.mdx, where the signature shows two positional parameters (config, detectedTests) but examples call it as await resolveTests({ config, detectedTests }). The generator's extractFunctionSig inlines destructured params but the signature line doesn't reflect that the function takes a single object argument.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (19)
fern/pages/reference/schemas/runcode.md-58-64 (1)
58-64:⚠️ Potential issue | 🟡 Minor
stdiodoes not match the shown Python output.At Line 58, the code prints
Hello from Python(no exclamation), but Line 63 documentsHello from Python!. The example should be internally consistent.Proposed doc fix
- "code": "print('Hello from Python')", + "code": "print('Hello from Python!')",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/runcode.md` around lines 58 - 64, The example is inconsistent: the "code" field prints "Hello from Python" while the "stdio" field shows "Hello from Python!"; update one so they match—either change the "code" value in the runcode example to "print('Hello from Python!')" or change the "stdio" value to "Hello from Python" (no exclamation); ensure you update the matching fields "code" and "stdio" (and keep "path", "workingDirectory", "exitCodes" unchanged) so the example is internally consistent.fern/pages/reference/schemas/context.md-20-20 (1)
20-20:⚠️ Potential issue | 🟡 Minor
browserstable row likely needs formatting to satisfy markdownlint and readability.The changed row is flagged for pipe style/column count (
MD055,MD056). Consider formatting the type cell so the table parser consistently sees 4 columns and add an explicit default value marker.Proposed formatting adjustment
-browsers | one of:<br/>- string<br/>- object([Browser](/reference/schemas/browser))<br/>- array of one of:<br/>- string<br/>- object([Browser](/reference/schemas/browser)) | Optional. Browsers to run tests on. | +browsers | one of:<br/>- string<br/>- object([Browser](/reference/schemas/browser))<br/>- array of one of:<br/> - string<br/> - object([Browser](/reference/schemas/browser)) | Optional. Browsers to run tests on. | ``🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/context.md` at line 20, The table row for the "browsers" field is producing MD055/MD056 errors because the "Type" cell contains unescaped pipes/newlines that make the parser think the row has the wrong number of columns; update the "browsers" row so it has exactly four pipe-separated columns by normalizing the Type cell (e.g., combine options into one cell using inline code spans and commas or HTML <br/> for line breaks, and escape any literal "|" if needed) and add an explicit default marker (e.g., "Optional" or "—") in the Default column; locate the row referencing "browsers" in context.md and modify that single table row to ensure consistent column count and explicit default value.fern/pages/reference/schemas/click-element-detailed.md-15-21 (1)
15-21:⚠️ Potential issue | 🟡 MinorTable rows appear to violate markdownlint and may render inconsistently.
The changed field rows are flagged for table pipe style/column count (
MD055,MD056). Also, “element finding fields” should be “element-finding fields” on Lines 15-16.Proposed cleanup
-elementText | string | Optional. Display text of the element to click. If combined with other element finding fields, the element must match all specified criteria. | -selector | string | Optional. Selector of the element to click. If combined with other element finding fields, the element must match all specified criteria. | +elementText | string | Optional. Display text of the element to click. If combined with other element-finding fields, the element must match all specified criteria. | `` +selector | string | Optional. Selector of the element to click. If combined with other element-finding fields, the element must match all specified criteria. | `` -elementId | string | Optional. ID attribute of the element to click. Supports exact match or regex pattern using /pattern/ syntax. | +elementId | string | Optional. ID attribute of the element to click. Supports exact match or regex pattern using `/pattern/` syntax. | `` -elementTestId | string | Optional. data-testid attribute of the element to click. Supports exact match or regex pattern using /pattern/ syntax. | +elementTestId | string | Optional. `data-testid` attribute of the element to click. Supports exact match or regex pattern using `/pattern/` syntax. | `` -elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. | +elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using `/pattern/` syntax. The element must have all specified classes. | `` -elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. | +elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting `/pattern/` regex), numbers, or booleans. Boolean `true` matches attribute presence, and `false` matches absence. | `` -elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. | +elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using `/pattern/` syntax. | ``🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/click-element-detailed.md` around lines 15 - 21, The table rows for the schema fields (elementText, selector, elementId, elementTestId, elementClass, elementAttribute, elementAria) violate markdown table pipe/column rules and use inconsistent HTML line breaks; update the table to a proper Markdown pipe table with the same number of columns on each row and remove or replace <br/> with acceptable Markdown (e.g., inline "one of: string | array of string" or a short parenthetical) so MD055/MD056 are satisfied, and fix the wording by replacing "element finding fields" with the hyphenated "element-finding fields" in the elementText and selector descriptions.fern/pages/reference/schemas/go-to-url-detailed.md-17-18 (1)
17-18:⚠️ Potential issue | 🟡 MinorNormalize table rows to avoid markdownlint column-count failures.
The modified rows are triggering MD055/MD056 warnings. Give the
Defaultcell an explicit value (for example,None) and keep row delimiters consistent.🧹 Proposed fix
timeout | integer | Optional. Maximum time in milliseconds to wait for the page to be ready. If exceeded, the goTo action fails.<br/><br/>Minimum: 0 | `30000` -waitUntil | object | Optional. Configuration for waiting conditions after navigation. | +waitUntil | object | Optional. Configuration for waiting conditions after navigation. | None🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/go-to-url-detailed.md` around lines 17 - 18, The table rows for the "timeout" and "waitUntil" schema entries are missing explicit Default cell values and have inconsistent row delimiters causing markdownlint MD055/MD056; update the "timeout" row to keep the three-column pipe format and keep its Default as `30000`, and add an explicit Default value (e.g., `None`) for the "waitUntil" row while preserving the same pipe-delimited column structure so both "timeout" and "waitUntil" rows are normalized and consistent.fern/pages/docs/tests/overview.mdx-8-8 (1)
8-8:⚠️ Potential issue | 🟡 MinorFix grammar in the test specification definition.
Line 8 should read “are a collection,” not “are collection.”
✏️ Proposed fix
-- **Test specification**: The highest-level component, test specifications (or specs) are collection of tests that should run together. +- **Test specification**: The highest-level component, test specifications (or specs) are a collection of tests that should run together.As per coding guidelines, documentation must follow the Google Developer Style Guide, including clear and correct grammar.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/tests/overview.mdx` at line 8, Fix the grammar in the "**Test specification**" definition: change the phrase "are collection of tests" to "are a collection of tests" so the sentence reads "test specifications (or specs) are a collection of tests that should run together." Locate the paragraph containing the "**Test specification**" heading and update that sentence accordingly.fern/pages/docs/tests/inline.mdx-239-239 (1)
239-239:⚠️ Potential issue | 🟡 MinorChange
stopRecordfrom empty string to booleantrue.The
stopRecordstep should use a boolean value, not an empty string. According to the schema,stopRecordtakes a boolean value—specificallystopRecord: trueto finalize and save the recording. Update line 239 from{"stopRecord": ""}to{"stopRecord": true}.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/tests/inline.mdx` at line 239, The step comment uses an empty string for stopRecord; change the step marker's JSON so stopRecord is a boolean true (i.e., replace {"stopRecord": ""} with {"stopRecord": true}) in the step comment (the {/* step ... */} block) so the recording finalizes per the schema.fern/pages/reference/schemas/record.md-31-38 (1)
31-38:⚠️ Potential issue | 🟡 MinorLikely incorrect type for
overwritevalue.Line 36 uses
"overwrite": "true"(a string) instead of"overwrite": true(a boolean). This appears to be a typo in the example since boolean values don't typically need quotes in JSON.Proposed fix
"record": { "path": "results.mp4", "directory": "static/media", - "overwrite": "true" + "overwrite": true }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/record.md` around lines 31 - 38, The JSON example uses a string for the overwrite field ("overwrite": "true") which is incorrect; update the example so the overwrite property under the record object is a boolean (overwrite: true) rather than a quoted string, ensuring the JSON example reflects a boolean value for overwrite.fern/pages/reference/schemas/http-request-detailed.md-14-14 (1)
14-14:⚠️ Potential issue | 🟡 MinorLine 14 table row needs a proper Default cell value.
The updated
openApirow is functionally fine, but markdownlint flags formatting (MD055/MD056).Suggested patch
-openApi | one of:<br/>- string<br/>- object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | +openApi | one of:<br/>- string<br/>- object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/http-request-detailed.md` at line 14, The table row for the openApi field is missing an explicit Default cell which triggers markdownlint MD055/MD056; update the table row for openApi in http-request-detailed.md to include a proper Default column value (for example "-" or "None"/"null") so every table cell is present and the row reads: name | type | description | Default, ensuring the openApi entry has that Default filled in.fern/pages/reference/schemas/resolved-context.md-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorLine 15 table row needs explicit default value for markdownlint compliance.
The updated
openApirow currently triggers MD055/MD056. Populate the Default cell explicitly.Suggested patch
-openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | +openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/resolved-context.md` at line 15, The table row for the schema property named "openApi" currently leaves the Default column blank; update the row in resolved-context.md so the Default cell contains an explicit value (e.g., "None" or "N/A") to satisfy markdownlint rules (MD055/MD056)—find the row with the "openApi | array of object([openApi](/reference/schemas/openapi))" entry and populate its Default column with the chosen explicit default.fern/pages/reference/schemas/specification.md-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorLine 15 should include an explicit Default cell.
Current row formatting triggers markdownlint (MD055/MD056).
Suggested patch
-openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | +openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/specification.md` at line 15, The table row for the "openApi" schema entry is missing an explicit Default cell which breaks markdown table column alignment; update the row for the openApi entry (the line containing "openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided.") to include a fourth column value (e.g., "—", "None", or "N/A") as the Default cell so the table has four columns and satisfies markdownlint MD055/MD056.fern/pages/reference/schemas/test.md-20-20 (1)
20-20:⚠️ Potential issue | 🟡 MinorLine 20 has a markdown table formatting issue (MD055/MD056).
Please make the Default column explicit to prevent lint failures.
Suggested patch
-openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | +openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/test.md` at line 20, The markdown table row for the "openApi" schema entry currently leaves the Default column empty causing MD055/MD056 lint failures; update the row for the "openApi" entry (the line containing "openApi | array of object([openApi](/reference/schemas/openapi)) | Optional. No description provided. |") to include an explicit Default value (e.g., "-" or "None" or "null") in the final column so the table has an explicit Default column value.fern/pages/reference/schemas/type.md-16-22 (1)
16-22:⚠️ Potential issue | 🟡 MinorFix table row formatting to stop markdownlint failures.
Line 16 is currently parsed as an incomplete row, which cascades into warnings on Lines 19-22. Use an explicit Default value and consistent pipe style.
Suggested patch
-type | one of:<br/>- one of:<br/>- string<br/>- array of string<br/>- object([Type keys (detailed)](/reference/schemas/type-keys-detailed)) | Required. Type keys. To type special keys, begin and end the string with `$` and use the special key's keyword. For example, to type the Escape key, enter `$ESCAPE$`. | +type | one of:<br/>- one of:<br/>- string<br/>- array of string<br/>- object([Type keys (detailed)](/reference/schemas/type-keys-detailed)) | Required. Type keys. To type special keys, begin and end the string with `$` and use the special key's keyword. For example, to type the Escape key, enter `$ESCAPE$`. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/type.md` around lines 16 - 22, The table row for the "type" field is malformed causing markdownlint failures; update the table row for the "type" entry (the row starting with "type | one of:...") to use consistent pipe-delimited columns and include an explicit Default value (e.g., "Default: none" or appropriate default) so the row has the expected number of columns and trailing pipes; ensure subsequent rows/examples follow the same pipe style so the table closes correctly and markdown parsing warnings on the following lines disappear.fern/pages/reference/schemas/type-keys-detailed.md-17-22 (1)
17-22:⚠️ Potential issue | 🟡 MinorNew field rows should use explicit Default cells for valid table parsing.
Lines 17-22 trigger MD055/MD056; adding explicit defaults resolves the table-column ambiguity and keeps lint clean.
Suggested patch
-elementText | string | Optional. Display text of the element to type into. If combined with other element finding fields, the element must match all specified criteria. | -elementId | string | Optional. ID attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | -elementTestId | string | Optional. data-testid attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | -elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. | -elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. | -elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. | +elementText | string | Optional. Display text of the element to type into. If combined with other element-finding fields, the element must match all specified criteria. | `N/A` +elementId | string | Optional. ID attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | `N/A` +elementTestId | string | Optional. data-testid attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | `N/A` +elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. | `N/A` +elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. | `N/A` +elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/type-keys-detailed.md` around lines 17 - 22, The new schema table rows (elementText, elementId, elementTestId, elementClass, elementAttribute, elementAria) are missing explicit Default cells causing MD055/MD056; update each of these rows to include an explicit Default column entry (e.g., a clear placeholder like "-" or "None" or an explicit description such as "optional") so the table parser has an explicit default cell for every row and the linter stops flagging column ambiguity.fern/pages/reference/schemas/capture-screenshot-detailed.md-19-19 (1)
19-19:⚠️ Potential issue | 🟡 Minor
sourceIntegrationrow formatting should be adjusted for lint compliance.Line 19 is triggering MD055/MD056. Set an explicit default value in the final column.
Suggested patch
-sourceIntegration | object(sourceIntegration) | Optional. Information about the source integration for this screenshot, enabling upload of changed files back to the source CMS. Set automatically during test resolution for files from integrations. | +sourceIntegration | object(sourceIntegration) | Optional. Information about the source integration for this screenshot, enabling upload of changed files back to the source CMS. Set automatically during test resolution for files from integrations. | `N/A`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/capture-screenshot-detailed.md` at line 19, The markdown table row for sourceIntegration in capture-screenshot-detailed.md is tripping MD055/MD056 because the final column is empty; update the sourceIntegration row (the "sourceIntegration | object(sourceIntegration) | Optional. ..." entry) to include an explicit default in the last column (e.g., "Default: null" or "Default: None") and ensure the pipe-separated columns remain aligned so the table is lint-compliant.fern/pages/reference/api/resolve-paths.mdx-87-87 (1)
87-87:⚠️ Potential issue | 🟡 MinorUse one canonical
relativePathBasevalue list.Line 87 says
"config"/"file", but Line 123 says"config"/"cwd". Please standardize this to the actual supported values in all sections.Also applies to: 123-123
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/resolve-paths.mdx` at line 87, The docs inconsistently list allowed values for the relativePathBase option; update every occurrence in this document so they all use the single canonical, actual supported set of values for relativePathBase (e.g., replace the mismatched `"file"`/`"cwd"` usages so both descriptions show the same supported pair), and ensure the examples and explanatory sentences referencing relativePathBase use that same canonical value list.fern/pages/reference/api/detect-and-resolve-tests.mdx-1-4 (1)
1-4:⚠️ Potential issue | 🟡 MinorAdd a short
sidebar-titlefor this long page title.Given the long function name in
title, add a concisesidebar-titleto improve nav readability.As per coding guidelines, "Use short frontmatter sidebar titles when the main title is long in documentation pages."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/detect-and-resolve-tests.mdx` around lines 1 - 4, Add a short frontmatter key "sidebar-title" above the existing title block for this doc: insert a concise value like "Detect & Resolve Tests" (or similar short label) in the page frontmatter so the long title detectAndResolveTests() stays as the main title but the sidebar uses the shorter label; update the frontmatter near the existing title/description keys to include sidebar-title.fern/pages/reference/api/overview.mdx-93-93 (1)
93-93:⚠️ Potential issue | 🟡 MinorUpdate the configuration link to match the new file location.
The configuration page was moved from
fern/pages/docs/configuration.mdxtofern/pages/docs/config/configuration.mdxwith no slug override, so the correct link is/docs/config/configuration.Fix
-All API functions accept a configuration object with the same options available in the [configuration file](/docs/configuration). See the [`config`](/reference/schemas/config) schema for all available options. +All API functions accept a configuration object with the same options available in the [configuration file](/docs/config/configuration). See the [`config`](/reference/schemas/config) schema for all available options.Note: This same broken link pattern appears in 8 other documentation pages and should be fixed throughout.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/overview.mdx` at line 93, Update the broken configuration link in fern/pages/reference/api/overview.mdx by replacing the old href "/docs/configuration" with the new path "/docs/config/configuration" in the sentence that references the configuration file; also search for the same old link string "/docs/configuration" across the repo (the comment notes 8 other pages) and update them to "/docs/config/configuration" to keep all docs consistent.fern/pages/reference/schemas/integrations-options.md-15-15 (1)
15-15:⚠️ Potential issue | 🟡 MinorReplace placeholder text for
openApidescription.Line 15 still says “No description provided.” Please replace with a short functional description so this schema page is self-explanatory.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/integrations-options.md` at line 15, Update the placeholder description for the schema property named `openApi` in integrations-options.md: replace "No description provided." with a concise functional description (e.g., "Optional list of OpenAPI documents describing external integrations; each item should conform to the `openApi` schema and defines endpoints, operations, and models for an integration"). Ensure the new text remains brief, clarifies that the field is an optional array of `openApi` objects, and is added next to the existing `openApi | array of object([openApi](/reference/schemas/openapi))` entry.fern/pages/reference/api/run-tests.mdx-1-3 (1)
1-3:⚠️ Potential issue | 🟡 MinorAdd frontmatter
descriptionto this MDX page.Line 1-3 is missing a
description, which breaks consistency with the rest of the docs pages.As per coding guidelines, "Use frontmatter descriptions in MDX documentation pages".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/run-tests.mdx` around lines 1 - 3, The MDX frontmatter for the page with title runTests() is missing a description field; add a frontmatter line `description: "<short summary of what runTests() does>"` directly under the existing `title: runTests()` so the page follows the docs convention and provides a concise description for the runTests() reference page.
🧹 Nitpick comments (16)
fern/pages/reference/schemas/wait.md (1)
25-35: Clarify semantics for non-numericwaitexamples.The new examples are helpful, but readers may not understand what
"$WAIT_DURATION"andtrueresolve to at runtime, especially since Line 15 describes milliseconds. Add a short note under examples (or in Description) describing exact behavior for string/boolean values.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/wait.md` around lines 25 - 35, Add a short note under the examples (or in the Description) that explicitly states how non-numeric wait values are resolved: explain that string values like "$WAIT_DURATION" are runtime placeholders (e.g., environment/variable substitution) that are parsed into a numeric duration in milliseconds per the schema, and that boolean values like true are treated as a semantic toggle that maps to the schema’s default wait duration (state the exact default value used) — update the "wait" examples to include an inline explanation of the resolved form.fern/pages/reference/schemas/config.md (1)
179-183: Consider showing a non-defaultprocessDitaMapsvalue.Since default is already
true, this example is less illustrative; usingfalsemay better demonstrate behavior override.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/config.md` around lines 179 - 183, The example JSON currently shows the default value for processDitaMaps, which is unhelpful; update the sample to demonstrate a non-default behavior by setting "processDitaMaps": false so readers can see how to override the default and what effect that has in the config schema documentation (look for the example containing processDitaMaps to replace the value).fern/pages/reference/schemas/runshell.md (1)
29-33: Prefer a portable argument example over$USER.Line 31 uses a POSIX-style env var (
$USER), which may not behave consistently across shells/platforms. Consider replacing it with a neutral literal (or add a note that it is shell-dependent).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/runshell.md` around lines 29 - 33, The example in the runshell schema uses a POSIX-style environment variable "$USER" in the "args" array which is shell/platform-dependent; update the example to use a portable literal (e.g., replace "$USER" with a neutral value like "username" or "example_user") or add a brief note next to the "args" example explaining that environment variable expansion is shell-dependent and "$USER" may not work across all platforms so users should substitute an appropriate value for their environment; make the change around the "command" and "args" example shown in the diff.fern/pages/reference/schemas/browser.md (1)
27-28: Use concrete nested values forwindowandviewportin the example.Using
{}here makes the expected object shape less clear. A concrete example is easier to copy and reduces ambiguity.Proposed doc example update
{ "name": "chrome", "headless": true, - "window": {}, - "viewport": {} + "window": { + "width": 1280, + "height": 720 + }, + "viewport": { + "width": 1280, + "height": 720 + } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/browser.md` around lines 27 - 28, The example currently shows "window": {} and "viewport": {}, which is ambiguous; replace those empty objects with concrete nested example fields that reflect the expected shapes (e.g., for window include title, width, height, devicePixelRatio or similar fields; for viewport include width, height, scale or zoom, and scrollX/scrollY) so readers can see and copy the precise structure; update the example values for the "window" and "viewport" objects in the schema sample to use these explicit keys and realistic values.fern/pages/docs/tests/overview.mdx (1)
264-269: Avoid hard-coded credentials in the login pattern example.Use environment-variable placeholders so this starter pattern doesn’t normalize committed secrets.
🔐 Proposed fix
"steps": [ + { "loadVariables": ".env" }, { "goTo": "https://app.example.com/login" }, { "find": "input[name='email']" }, - { "type": ["user@example.com"] }, + { "type": ["$TEST_USER_EMAIL"] }, { "find": "input[name='password']" }, - { "type": ["password123"] }, + { "type": ["$TEST_USER_PASSWORD"] }, { "click": "button[type='submit']" }, { "find": ".dashboard" } ]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/tests/overview.mdx` around lines 264 - 269, The snippet in the login pattern contains hard-coded credentials in the steps (the "type" entries for "input[name='email']" and "input[name='password']"); replace those literal values with environment-variable placeholders (e.g., use process/env-style placeholders or template tokens like ${ENV_LOGIN_EMAIL} and ${ENV_LOGIN_PASSWORD}) so the example reads values from environment/config during test runs and no secrets are committed; update the two "type" steps accordingly and add a brief comment near the pattern indicating the placeholders must be set in CI/local env before running.fern/pages/docs/get-started/installation.mdx (1)
82-139: Add doc-test coverage for the new troubleshooting commands.The new section adds runnable snippets, but unlike earlier installation flows, it doesn’t include corresponding test steps. Please add/extend the relevant
.spec.jsoncoverage so these commands stay validated over time.Based on learnings, run documentation tests with
npm run doc-detectivewhen updating documentation features and review the corresponding.spec.jsonfile to see if the test needs to be updated.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/get-started/installation.mdx` around lines 82 - 139, Add doc-test coverage for the new Troubleshooting runnable snippets by updating the corresponding spec file (e.g., getting-started.spec.json) referenced in the example project layout; add test steps that validate the "Command not found" npm PATH instructions, the permission-error workaround (creating ~/.npm-global and setting npm prefix), the browser-launch notes (headless/CI flags and required Linux deps), and the reinstall module command (npm uninstall -g doc-detective && npm i -g doc-detective); ensure the project .doc-detective.json includes these new checks and then run the suite with npm run doc-detective to confirm tests pass.fern/pages/docs/get-started/cli-reference.mdx (1)
63-68: Use a description list for environment variable pairs.This section is pair-structured data (
Variable+Description), so it should use a description list instead of a table.♻️ Proposed fix
-| Variable | Description | -|----------|-------------| -| `DOC_DETECTIVE_CONFIG` | Path to a configuration file. Equivalent to `--config`. | -| `DOC_DETECTIVE_API` | API key for Doc Detective integrations. | -| `DOC_DETECTIVE_META` | Metadata to include with test results. | +`DOC_DETECTIVE_CONFIG` +: Path to a configuration file. Equivalent to `--config`. + +`DOC_DETECTIVE_API` +: API key for Doc Detective integrations. + +`DOC_DETECTIVE_META` +: Metadata to include with test results.As per coding guidelines, "Use description lists for pairs of related pieces of data in documentation."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/get-started/cli-reference.mdx` around lines 63 - 68, Replace the environment-variable table with a description list: remove the table rows for DOC_DETECTIVE_CONFIG, DOC_DETECTIVE_API, and DOC_DETECTIVE_META and render each variable as a term with its description (e.g., DOC_DETECTIVE_CONFIG → "Path to a configuration file. Equivalent to --config", DOC_DETECTIVE_API → "API key for Doc Detective integrations", DOC_DETECTIVE_META → "Metadata to include with test results") using MDX/HTML description-list markup (dl/dt/dd) or the project's supported description-list syntax so the pair-structured data follows the documentation guideline.fern/pages/docs/get-started/ci.mdx (1)
161-426: Please add doc-test verification coverage for the new CI snippets.This section adds many executable snippets across platforms; ensure corresponding doc-detective coverage/spec updates are included so examples stay valid.
Based on learnings, run documentation tests with
npm run doc-detectivewhen updating documentation features and review the corresponding.spec.jsonfile to see if the test needs to be updated.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/get-started/ci.mdx` around lines 161 - 426, Add doc-detective verification specs for the new CI/CD snippets by creating/updating .spec.json entries that exercise each provided example (GitLab .gitlab-ci.yml, Jenkinsfile, CircleCI config, Azure Pipelines, Travis .travis.yml and Docker usage) so they are executed with the same CLI flags shown in the docs (e.g., npx doc-detective --input ./docs and npx doc-detective --config .doc-detective.ci.json), ensure the spec(s) assert the tool runs successfully and writes results to ./test-results, add or verify an npm script "doc-detective" in package.json that runs the command used in the guidance, run npm run doc-detective locally to validate and update the corresponding .spec.json artifacts/expectations to match real output.fern/pages/reference/schemas/save-cookie-detailed.md (1)
19-19: Remove redundant "(optional)" from description.The description for
domainincludes "(optional)" at the end, but this is already indicated by "Optional." at the beginning of the description. This redundancy should be removed for consistency with other optional fields in the table.Suggested fix
-domain | string | Optional. Specific domain to filter the cookie by (optional). | +domain | string | Optional. Specific domain to filter the cookie by. |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/save-cookie-detailed.md` at line 19, Remove the redundant "(optional)" in the description for the domain field in the save-cookie-detailed schema: update the table row for the domain property so it reads "Optional. Specific domain to filter the cookie by." (refer to the domain field in fern/pages/reference/schemas/save-cookie-detailed.md).fern/pages/reference/schemas/find-element-detailed.md (2)
13-14: Consider hyphenating "element-finding" as compound adjective.Per the Google Developer Style Guide (referenced in coding guidelines), compound adjectives before nouns should be hyphenated: "element-finding fields" rather than "element finding fields."
Suggested fix
-elementText | string | Optional. Display text of the element to find. If combined with other element finding fields, the element must match all specified criteria. | -selector | string | Optional. Selector of the element to find. If combined with other element finding fields, the element must match all specified criteria. | +elementText | string | Optional. Display text of the element to find. If combined with other element-finding fields, the element must match all specified criteria. | +selector | string | Optional. Selector of the element to find. If combined with other element-finding fields, the element must match all specified criteria. |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/find-element-detailed.md` around lines 13 - 14, Update the two table descriptions for elementText and selector to hyphenate the compound adjective: change "element finding fields" to "element-finding fields" so both descriptions read "If combined with other element-finding fields, the element must match all specified criteria."; locate these phrases near the elementText and selector entries to apply the change.
34-34: Consider providing a meaningful example forelementAttribute.The empty object
{}doesn't demonstrate how to useelementAttribute. A concrete example would help users understand the expected format.Suggested example
- "elementAttribute": {}, + "elementAttribute": {"data-status": "active", "disabled": false},🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/find-element-detailed.md` at line 34, The example for elementAttribute is currently an empty object and should be replaced with a concrete illustrative object showing the expected key/value structure; update the example in the find-element-detailed.md snippet so that "elementAttribute" contains realistic attribute pairs (for example keys like "name" or actual attribute names and their values such as "href": "https://example.com", "class": "btn primary", or a small map { "data-id":"123", "aria-label":"close" }) to demonstrate the intended format and usage; ensure the example remains consistent with any surrounding schema fields and documentation language.scripts/generate-references.ts (1)
1354-1361: Avoid redundantbuildPageDefs()call.
buildPageDefs()is already called inmain()at line 1279. Calling it again here rebuilds all page definitions unnecessarily. Consider passing the existingpageDefsarray toregisterExtraComponentTitles()instead.Proposed fix
-function registerExtraComponentTitles() { +function registerExtraComponentTitles(pageDefs: PageDef[]) { // Walk all v3 schemas and register component schema titles const v3keys = Object.keys(allSchemas).filter((k) => k.endsWith("_v3")); // ... existing code ... // Walk nested properties for titles - for (const pd of buildPageDefs()) { + for (const pd of pageDefs) { if (pd.schema.properties) {And update the call site in
main():- registerExtraComponentTitles(); + registerExtraComponentTitles(pageDefs);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 1354 - 1361, The loop calls buildPageDefs() again causing redundant rebuilds; change registerExtraComponentTitles() to accept the existing pageDefs array (from main's buildPageDefs() call) instead of invoking buildPageDefs() internally, then iterate over that passed-in pageDefs and call registerNestedTitles(prop) for each property; update the call site in main() to pass pageDefs into registerExtraComponentTitles(pageDefs) so buildPageDefs() is only executed once.fern/pages/docs/config/configuration.mdx (1)
283-302: Consider varying sentence structure for better readability.The static analysis flagged that multiple successive sentences begin with "Contexts" (lines 283, 285, 300, 302). Consider rewording for variety:
- "Contexts in a spec override..." → "Spec-level contexts override..."
- "Contexts in a test override..." → "Test-level contexts override..."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/config/configuration.mdx` around lines 283 - 302, Reword repetitive sentences to vary sentence structure: change the heading/body line "Contexts in a specification" / sentence "Contexts in a spec override config-level contexts for all tests in that spec." to use "Spec-level contexts override config-level contexts for all tests in a spec." and change the heading/body "Contexts in a test" / sentence "Contexts in a test override both config- and spec-level contexts for that specific test." to "Test-level contexts override config- and spec-level contexts for that specific test."; update any matching occurrences around the JSON example (keys like "description", "runOn", "tests") so the new phrasing replaces the old one consistently.fern/pages/reference/schemas/click.md (1)
1-49: Documentation pages should use.mdxextension per coding guidelines.This file and other schema reference pages use
.mdextension, but the coding guidelines specify that documentation pages infern/pages/**/*must be MDX (.mdx) files. Since these files are auto-generated byscripts/generate-references.ts, the generator should output.mdxfiles instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/click.md` around lines 1 - 49, The generated schema reference file (e.g., click.md) uses the .md extension but must be .mdx per docs policy; update the generator (generate-references.ts) to output .mdx filenames instead of .md (e.g., emit click.mdx) and adjust the generator's template/output logic so the frontmatter and content are MDX-compatible; ensure any places that compute links or references (the code that constructs filenames/paths and the template used to render the schema pages) are updated to use the .mdx extension so generated pages land in the correct format.fern/pages/reference/api/run-tests.mdx (1)
15-16: Fill in parameter descriptions in the table.Line 15-16 leaves both parameter descriptions empty, which makes the API contract harder to use despite typed columns.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/run-tests.mdx` around lines 15 - 16, The parameter table is missing descriptions for `config` and `options`; update the table row for `config` to explain what configuration object it expects (e.g., shape, required fields, purpose—such as test runner settings, environment, or credentials) and mark it as required, and update the `options` row to describe optional flags or overrides (e.g., timeout, verbose, filters) and how they alter behavior; reference the parameter names `config` and `options` so readers can map these descriptions to the function/API signature and include a short example or link to the detailed type definition if available.fern/pages/reference/api/resolve-tests.mdx (1)
16-17: Add concrete descriptions forconfiganddetectedTests.The parameters are required but undocumented in the description column, which reduces clarity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/api/resolve-tests.mdx` around lines 16 - 17, The table documenting parameters for the resolve-tests API is missing descriptive text for the required parameters `config` and `detectedTests`; update the MDX table row descriptions to concisely explain each parameter’s shape and purpose (e.g., `config` — object with resolution settings such as {projectRoot:string, patterns:string[], options?:object}; `detectedTests` — array of test metadata objects containing at least {path:string, framework:string, matches?:string[]}) so consumers know what to pass and what fields are required/optional; edit the rows for `config` and `detectedTests` in the parameter table on the resolve-tests page to include these concrete descriptions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8cf35a9e-795d-41da-98aa-6d6d6ea56f56
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (68)
fern/docs.ymlfern/pages/contribute/templates/troubleshooting.mdxfern/pages/contribute/templates/tutorial.mdxfern/pages/docs/config/configuration.mdxfern/pages/docs/config/contexts.mdfern/pages/docs/get-started/ci.mdxfern/pages/docs/get-started/cli-reference.mdxfern/pages/docs/get-started/installation.mdxfern/pages/docs/tests/inline.mdxfern/pages/docs/tests/overview.mdxfern/pages/reference/api/detect-and-resolve-tests.mdxfern/pages/reference/api/detect-tests.mdxfern/pages/reference/api/get-runner.mdxfern/pages/reference/api/overview.mdxfern/pages/reference/api/read-file.mdxfern/pages/reference/api/resolve-paths.mdxfern/pages/reference/api/resolve-tests.mdxfern/pages/reference/api/run-tests.mdxfern/pages/reference/glossary.mdxfern/pages/reference/schemas/browser.mdfern/pages/reference/schemas/capture-screenshot-detailed.mdfern/pages/reference/schemas/check-link-detailed.mdfern/pages/reference/schemas/checklink.mdfern/pages/reference/schemas/click-element-detailed.mdfern/pages/reference/schemas/click.mdfern/pages/reference/schemas/common.mdfern/pages/reference/schemas/config.mdfern/pages/reference/schemas/context.mdfern/pages/reference/schemas/crop-by-element-detailed.mdfern/pages/reference/schemas/draganddrop.mdfern/pages/reference/schemas/file-type-custom.mdfern/pages/reference/schemas/file-type-executable.mdfern/pages/reference/schemas/find-element-detailed.mdfern/pages/reference/schemas/find.mdfern/pages/reference/schemas/go-to-url-detailed.mdfern/pages/reference/schemas/goto.mdfern/pages/reference/schemas/http-request-detailed.mdfern/pages/reference/schemas/httprequest.mdfern/pages/reference/schemas/inline-statement-definition.mdfern/pages/reference/schemas/integrations-options.mdfern/pages/reference/schemas/load-cookie-detailed.mdfern/pages/reference/schemas/loadcookie.mdfern/pages/reference/schemas/loadvariables.mdfern/pages/reference/schemas/markup-definition.mdfern/pages/reference/schemas/openapi.mdfern/pages/reference/schemas/record.mdfern/pages/reference/schemas/request-body-object.mdfern/pages/reference/schemas/request-headers-object.mdfern/pages/reference/schemas/request-parameters.mdfern/pages/reference/schemas/resolved-context.mdfern/pages/reference/schemas/response-body-object.mdfern/pages/reference/schemas/response-headers.mdfern/pages/reference/schemas/response.mdfern/pages/reference/schemas/run-code-detailed.mdfern/pages/reference/schemas/run-shell-command-detailed.mdfern/pages/reference/schemas/runcode.mdfern/pages/reference/schemas/runshell.mdfern/pages/reference/schemas/save-cookie-detailed.mdfern/pages/reference/schemas/savecookie.mdfern/pages/reference/schemas/screenshot.mdfern/pages/reference/schemas/specification.mdfern/pages/reference/schemas/stoprecord.mdfern/pages/reference/schemas/test.mdfern/pages/reference/schemas/type-keys-detailed.mdfern/pages/reference/schemas/type.mdfern/pages/reference/schemas/wait.mdpackage.jsonscripts/generate-references.ts
💤 Files with no reviewable changes (2)
- fern/pages/reference/schemas/common.md
- fern/pages/docs/config/contexts.md
…sues, test examples
- Replace invalid HTML comments (<!-- -->) with MDX JSX comments ({/* */}) in all 7 API reference pages
- Fix detectTests() signature and parameter to use object destructuring { config }
- Fix resolveTests() signature to use object destructuring { config, detectedTests }
- Fix resolvePaths() signature to use object destructuring
- Fix readFile() signature and parameter to use object destructuring { fileURLOrPath }
- Revert type.md title from 'typeKeys' back to 'type'
- Fix type-keys-detailed.md cross-reference from [typeKeys] to [type]
- Fix statusCode (singular, inside response) to statusCodes array (top-level) in test examples
- Remove nonexistent --exit-on-fail CLI flag reference from ci.mdx
- Fix go-to-url-detailed.md example: invalid url/origin values -> /example and https://www.example.com
- Fix runcode.md example: 'return false' (invalid Node.js) -> 'process.exit(1)'
- Deduplicate repeated object([Common]) entries in markup-definition.md actions field
- Fix generate-references.ts: pass pageDefs to registerExtraComponentTitles() to avoid redundant buildPageDefs() call
- Fix generate-references.ts: deduplicate rendered type strings with Set to prevent duplicate entries
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
scripts/generate-references.ts (1)
1157-1158:⚠️ Potential issue | 🟠 MajorUpdate marker constants to use JSX comment syntax with legacy HTML comment fallback.
The generator searches for and emits HTML comment markers (
<!-- CUSTOM CONTENT START -->), but the existing MDX files use JSX comment markers ({/* CUSTOM CONTENT START */}). This mismatch causes the preservation logic to fail—the markers are not found in existing files, forcing a fallback to section-based detection instead of explicit marker preservation. Regenerating pages will emit incorrect HTML comment syntax instead of JSX comments.Fix by updating the marker constants to use JSX syntax and supporting the legacy HTML format as a fallback:
Migration-safe fix
-const CUSTOM_START = "<!-- CUSTOM CONTENT START -->"; -const CUSTOM_END = "<!-- CUSTOM CONTENT END -->"; +const CUSTOM_START = "{/* CUSTOM CONTENT START */}"; +const CUSTOM_END = "{/* CUSTOM CONTENT END */}"; +const LEGACY_CUSTOM_START = "<!-- CUSTOM CONTENT START -->"; +const LEGACY_CUSTOM_END = "<!-- CUSTOM CONTENT END -->"; @@ - const startIdx = existing.indexOf(CUSTOM_START); - const endIdx = existing.indexOf(CUSTOM_END); - if (startIdx !== -1 && endIdx !== -1) { + const startToken = existing.includes(CUSTOM_START) + ? CUSTOM_START + : LEGACY_CUSTOM_START; + const endToken = existing.includes(CUSTOM_END) + ? CUSTOM_END + : LEGACY_CUSTOM_END; + const startIdx = existing.indexOf(startToken); + const endIdx = existing.indexOf(endToken); + if (startIdx !== -1 && endIdx !== -1) { customContent = existing.substring( - startIdx + CUSTOM_START.length, + startIdx + startToken.length, endIdx );Also applies to lines 1186–1192 and 1268–1270.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 1157 - 1158, Update the marker constants CUSTOM_START and CUSTOM_END in generate-references.ts to use JSX comment syntax (e.g. {/* CUSTOM CONTENT START */} / {/* CUSTOM CONTENT END */}) and change the preservation/search logic to also accept the legacy HTML markers (<!-- CUSTOM CONTENT START --> / <!-- CUSTOM CONTENT END -->) as a fallback; ensure any emit logic that writes markers (the same symbols CUSTOM_START/CUSTOM_END) writes the JSX form and that matching/regex code paths (the other occurrences of the markers referenced in the file) check for both JSX and HTML variants so existing MDX files with either marker are recognized and preserved.
🧹 Nitpick comments (2)
fern/pages/reference/schemas/type.md (1)
10-10: Normalize link label casing for readability consistency.Consider renaming
testtoTestto match the title-style labels used in adjacent links.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/reference/schemas/type.md` at line 10, Update the link label text from "test" to "Test" to normalize title-style casing: find the markdown link whose label is "test" (the text inside the brackets) pointing to "/reference/schemas/test" and change only the visible label to "Test" while keeping the URL unchanged.fern/pages/docs/get-started/ci.mdx (1)
165-333: Use Fern MDX components to improve scanability of multi-platform examples.This new section is useful, but the long sequence of large blocks is hard to navigate. Grouping platform examples with
<Tabs>(or collapsible sections) would improve readability without changing content.As per coding guidelines, "Use Fern Docs MDX components when they improve the reader experience".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@fern/pages/docs/get-started/ci.mdx` around lines 165 - 333, The CI examples section contains many large code blocks (e.g., the "GitLab CI/CD" and "Multi-platform GitLab CI" groups, plus Jenkins, CircleCI, Azure Pipelines, Travis CI headings) that hurt scanability; wrap related platform examples in Fern MDX UI components (for example use <Tabs> with per-platform <TabItem> or collapsible panels) so each CI platform is collapsible/tabbed rather than a long vertical list, update the headings inside the MDX (e.g., "GitLab CI/CD", "Multi-platform GitLab CI", "Azure Pipelines", "Travis CI") to be the tab labels or panel summaries, and ensure existing code blocks and relative references (like .gitlab-ci.yml, .doc-detective-base, azure-pipelines.yml) remain unchanged except for placement inside those components.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fern/pages/docs/get-started/ci.mdx`:
- Line 171: Update all CI examples that pin the Docker image "image: node:18"
(and any other occurrences of "node:18" in the file) to a supported LTS like
"node:20" or "node:22" (preferably node:22+ for longer support); search for the
exact token "node:18" across the document (notably the occurrences referenced in
the comment) and replace each with the chosen LTS tag, ensuring any accompanying
text that mentions Node.js v18 is updated to the new version and that examples
continue to work with the updated image.
- Around line 238-247: The CircleCI job caches node_modules keyed by dd-deps-{{
checksum "package-lock.json" }} but installs Doc Detective globally with npm i
-g doc-detective, so the node_modules cache is ineffective and the checksum will
error if package-lock.json is missing; update the job to either remove the
restore_cache/save_cache blocks entirely or replace them to cache the npm global
prefix and npm cache (e.g., cache paths like ~/.npm-global and ~/.npm) and stop
using dd-deps-{{ checksum "package-lock.json" }} as the key so the job no longer
depends on package-lock.json when installing global tools.
In `@fern/pages/reference/api/run-tests.mdx`:
- Around line 1-3: The MDX frontmatter for the page with title "runTests()" is
missing a description; edit the frontmatter at the top of run-tests.mdx to add a
concise description string (frontmatter key "description") that summarizes the
page (e.g., what runTests() does and when to use it), ensuring the frontmatter
block contains both title: runTests() and the new description field.
In `@fern/pages/reference/schemas/runcode.md`:
- Around line 58-64: The example in runcode.md has a mismatch between the "code"
and "stdio" fields — update the "code" entry to print the exact expected output
by changing "code": "print('Hello from Python')" to "code": "print('Hello from
Python!')", then run the docs tests with npm run doc-detective and adjust the
corresponding .spec.json if the test expectation needs updating.
- Line 23: The example string "console.log('Hello, ${process.env.USER}!');" uses
single quotes so ${process.env.USER} won't be interpolated; update the snippet
in the "code" value to use a template literal (backticks) like
console.log(`Hello, ${process.env.USER}!`); so the env var is evaluated and
printed.
In `@fern/pages/reference/schemas/type-keys-detailed.md`:
- Around line 17-22: Table rows for the new fields elementText, elementId,
elementTestId, elementClass, elementAttribute, and elementAria are missing the
fourth "Default" column cell, causing MD056; update each corresponding row in
type-keys-detailed.md to include the missing Default cell (use an appropriate
default value such as an empty cell or a dash/“—” if no default applies) so
every row has four cells and the markdown table is well-formed.
---
Duplicate comments:
In `@scripts/generate-references.ts`:
- Around line 1157-1158: Update the marker constants CUSTOM_START and CUSTOM_END
in generate-references.ts to use JSX comment syntax (e.g. {/* CUSTOM CONTENT
START */} / {/* CUSTOM CONTENT END */}) and change the preservation/search logic
to also accept the legacy HTML markers (<!-- CUSTOM CONTENT START --> / <!--
CUSTOM CONTENT END -->) as a fallback; ensure any emit logic that writes markers
(the same symbols CUSTOM_START/CUSTOM_END) writes the JSX form and that
matching/regex code paths (the other occurrences of the markers referenced in
the file) check for both JSX and HTML variants so existing MDX files with either
marker are recognized and preserved.
---
Nitpick comments:
In `@fern/pages/docs/get-started/ci.mdx`:
- Around line 165-333: The CI examples section contains many large code blocks
(e.g., the "GitLab CI/CD" and "Multi-platform GitLab CI" groups, plus Jenkins,
CircleCI, Azure Pipelines, Travis CI headings) that hurt scanability; wrap
related platform examples in Fern MDX UI components (for example use <Tabs> with
per-platform <TabItem> or collapsible panels) so each CI platform is
collapsible/tabbed rather than a long vertical list, update the headings inside
the MDX (e.g., "GitLab CI/CD", "Multi-platform GitLab CI", "Azure Pipelines",
"Travis CI") to be the tab labels or panel summaries, and ensure existing code
blocks and relative references (like .gitlab-ci.yml, .doc-detective-base,
azure-pipelines.yml) remain unchanged except for placement inside those
components.
In `@fern/pages/reference/schemas/type.md`:
- Line 10: Update the link label text from "test" to "Test" to normalize
title-style casing: find the markdown link whose label is "test" (the text
inside the brackets) pointing to "/reference/schemas/test" and change only the
visible label to "Test" while keeping the URL unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 29508ae4-e809-4dd0-86bc-336b29d74eb8
📒 Files selected for processing (15)
fern/pages/docs/get-started/ci.mdxfern/pages/docs/tests/overview.mdxfern/pages/reference/api/detect-and-resolve-tests.mdxfern/pages/reference/api/detect-tests.mdxfern/pages/reference/api/get-runner.mdxfern/pages/reference/api/read-file.mdxfern/pages/reference/api/resolve-paths.mdxfern/pages/reference/api/resolve-tests.mdxfern/pages/reference/api/run-tests.mdxfern/pages/reference/schemas/go-to-url-detailed.mdfern/pages/reference/schemas/markup-definition.mdfern/pages/reference/schemas/runcode.mdfern/pages/reference/schemas/type-keys-detailed.mdfern/pages/reference/schemas/type.mdscripts/generate-references.ts
✅ Files skipped from review due to trivial changes (3)
- fern/pages/reference/api/resolve-paths.mdx
- fern/pages/reference/api/detect-and-resolve-tests.mdx
- fern/pages/reference/api/get-runner.mdx
🚧 Files skipped from review as they are similar to previous changes (3)
- fern/pages/reference/api/resolve-tests.mdx
- fern/pages/docs/tests/overview.mdx
- fern/pages/reference/api/read-file.mdx
| elementText | string | Optional. Display text of the element to type into. If combined with other element finding fields, the element must match all specified criteria. | | ||
| elementId | string | Optional. ID attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | | ||
| elementTestId | string | Optional. data-testid attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. | | ||
| elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. | | ||
| elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. | | ||
| elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. | |
There was a problem hiding this comment.
Add the missing Default column cell for each new field row.
At Line 17–Line 22, each row currently has only 3 cells in a 4-column table, which triggers markdownlint MD056 and can render inconsistently.
Suggested fix
-elementText | string | Optional. Display text of the element to type into. If combined with other element finding fields, the element must match all specified criteria. |
-elementId | string | Optional. ID attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. |
-elementTestId | string | Optional. data-testid attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. |
-elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. |
-elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. |
-elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. |
+elementText | string | Optional. Display text of the element to type into. If combined with other element-finding fields, the element must match all specified criteria. |
+elementId | string | Optional. ID attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. |
+elementTestId | string | Optional. data-testid attribute of the element to find. Supports exact match or regex pattern using /pattern/ syntax. |
+elementClass | one of:<br/>- string<br/>- array of string | Optional. Class or array of classes that the element must have. Each class supports exact match or regex pattern using /pattern/ syntax. Element must have all specified classes. |
+elementAttribute | object | Optional. Object of attribute key-value pairs that the element must have. Values can be strings (supporting /pattern/ regex), numbers, or booleans. Boolean true matches attribute presence, false matches absence. |
+elementAria | string | Optional. Computed accessible name of the element per ARIA specification. Supports exact match or regex pattern using /pattern/ syntax. | 🧰 Tools
🪛 LanguageTool
[grammar] ~17-~17: Use a hyphen to join words.
Context: ...ype into. If combined with other element finding fields, the element must match a...
(QB_NEW_EN_HYPHEN)
🪛 markdownlint-cli2 (0.21.0)
[warning] 17-17: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 17-17: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
[warning] 18-18: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 18-18: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
[warning] 19-19: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 19-19: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
[warning] 20-20: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 20-20: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
[warning] 21-21: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 21-21: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
[warning] 22-22: Table pipe style
Expected: no_leading_or_trailing; Actual: trailing_only; Unexpected trailing pipe
(MD055, table-pipe-style)
[warning] 22-22: Table column count
Expected: 4; Actual: 3; Too few cells, row will be missing data
(MD056, table-column-count)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fern/pages/reference/schemas/type-keys-detailed.md` around lines 17 - 22,
Table rows for the new fields elementText, elementId, elementTestId,
elementClass, elementAttribute, and elementAria are missing the fourth "Default"
column cell, causing MD056; update each corresponding row in
type-keys-detailed.md to include the missing Default cell (use an appropriate
default value such as an empty cell or a dash/“—” if no default applies) so
every row has four cells and the markdown table is well-formed.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 68 out of 69 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
fern/pages/docs/tests/overview.mdx
Outdated
| Use `before` and `after` properties to run steps before and after a test: | ||
|
|
||
| ```json | ||
| { | ||
| "tests": [ | ||
| { | ||
| "description": "Test with setup and cleanup", | ||
| "before": [ | ||
| { "loadVariables": ".env" }, | ||
| { "goTo": "$SITE_URL" } | ||
| ], | ||
| "steps": [ | ||
| { "find": "h1" }, | ||
| { "screenshot": "homepage.png" } | ||
| ], | ||
| "after": [ | ||
| { "screenshot": "final-state.png" } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
The "Setup and cleanup" section uses before and after properties as inline arrays of step objects. However, per the test schema (fern/pages/reference/schemas/test.md, line 21-22), before and after are string types (paths to test specification files), not step arrays. The example should use file paths like "before": "setup.json" instead of inline step arrays.
| | `beforeAny` | array | Steps to run before any tests start. | | ||
| | `afterAll` | array | Steps to run after all tests complete. | | ||
|
|
||
| ```json | ||
| { | ||
| "input": ".", | ||
| "beforeAny": [ | ||
| { "loadVariables": ".env" } | ||
| ], | ||
| "afterAll": [ | ||
| { "runShell": "echo Tests complete" } |
There was a problem hiding this comment.
The beforeAny and afterAll options are documented here as accepting arrays of step objects (e.g., [{ "loadVariables": ".env" }]). However, the config schema (fern/pages/reference/schemas/config.md, lines 20-21) shows they accept string or array of string (paths to test specification files), not inline step arrays. The example should use file paths like "beforeAny": ["./setup.spec.json"].
| | `beforeAny` | array | Steps to run before any tests start. | | |
| | `afterAll` | array | Steps to run after all tests complete. | | |
| ```json | |
| { | |
| "input": ".", | |
| "beforeAny": [ | |
| { "loadVariables": ".env" } | |
| ], | |
| "afterAll": [ | |
| { "runShell": "echo Tests complete" } | |
| | `beforeAny` | string or array of string | Test specification file(s) to run before any tests start. | | |
| | `afterAll` | string or array of string | Test specification file(s) to run after all tests complete. | | |
| ```json | |
| { | |
| "input": ".", | |
| "beforeAny": [ | |
| "./setup.spec.json" | |
| ], | |
| "afterAll": [ | |
| "./teardown.spec.json" |
| "openApi": { | ||
| "definition": "./openapi.yaml", | ||
| "server": "https://api.example.com" | ||
| } |
There was a problem hiding this comment.
The OpenAPI integration example is incorrect. The integrations.openApi property accepts an array of openApi schema objects (as per integrations-options.md line 15 and openapi.md), not a single object with definition and server keys. The definition property in the openApi schema is ReadOnly and auto-resolved from descriptionPath. The example should use descriptionPath and be wrapped in an array, for example: "openApi": [{ "descriptionPath": "./openapi.yaml", "server": "https://api.example.com" }].
| "openApi": { | |
| "definition": "./openapi.yaml", | |
| "server": "https://api.example.com" | |
| } | |
| "openApi": [ | |
| { | |
| "descriptionPath": "./openapi.yaml", | |
| "server": "https://api.example.com" | |
| } | |
| ] |
| const SOURCE_REPO = path.resolve(ROOT, "..", "doc-detective"); | ||
| const SCHEMAS_JSON = path.join( | ||
| SOURCE_REPO, | ||
| "src/common/src/schemas/schemas.json" | ||
| ); |
There was a problem hiding this comment.
The script requires a sibling doc-detective repository cloned at ../doc-detective relative to this project root (line 23). This path assumption is not documented anywhere in the script or a README, making it fragile for other contributors. The script should either validate the path and fail with a clear error message, or accept a configurable --source-repo argument.
| ## Parameters | ||
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|-------------| | ||
| | `config` | any | Yes | | | ||
| | `options` | any | No | | | ||
|
|
There was a problem hiding this comment.
The generated API pages (e.g., run-tests.mdx) have parameter types listed as any in the Parameters table. This is because extractFunctionSig falls back to "any" when parameters don't have explicit type annotations or when the type is not a TypeLiteralNode. The generated documentation is not useful for API consumers since all parameter types show as any. Consider reading the full TypeScript type text even for non-literal types, or enriching the generated docs with descriptions from JSDoc.
scripts/generate-references.ts
Outdated
| const CUSTOM_START = "<!-- CUSTOM CONTENT START -->"; | ||
| const CUSTOM_END = "<!-- CUSTOM CONTENT END -->"; |
There was a problem hiding this comment.
The generator script defines CUSTOM_START = "<!-- CUSTOM CONTENT START -->" and CUSTOM_END = "<!-- CUSTOM CONTENT END -->" (HTML comments, lines 1157-1158), but the generated .mdx files use JSX comments {/* CUSTOM CONTENT START */} and {/* CUSTOM CONTENT END */}. On the next run of generate, the script will fail to locate the existing custom content markers (indexOf will return -1`) and fall back to the heuristic path-based extraction, potentially duplicating or losing manually-added content.
- Update all CI examples from node:18 (EOL) to node:22
- Remove ineffective CircleCI cache blocks (global npm install doesn't use node_modules)
- Add frontmatter description to run-tests.mdx
- Fix template literal in runcode.md JS example (single quotes -> backticks for env var interpolation)
- Fix Python stdio mismatch: print('Hello from Python') -> print('Hello from Python!')
- tests/overview.mdx: fix before/after examples to use spec file paths (not inline step arrays), matching the string-typed schema fields - config/configuration.mdx: fix beforeAny/afterAll table types and examples to use spec file paths; fix openApi example to use array with descriptionPath - generate-references.ts: fix CUSTOM_START/CUSTOM_END markers to use JSX comments matching generated .mdx files; add validation for missing source repo; expand destructured binding elements individually
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 68 out of 69 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ```yaml | ||
| doc-detective: | ||
| image: node:22 | ||
| artifacts: | ||
| paths: | ||
| - test-results/ | ||
| when: always | ||
| ``` |
There was a problem hiding this comment.
The GitLab CI basic job snippet is incomplete — it defines image and artifacts but is missing a script: section that actually installs and runs Doc Detective. Without a script key, the job will fail to execute. Compare with the multi-platform example immediately below it, which correctly includes script: with the install and run commands.
| | `relativePathBase` | string | `"config"` | Base for resolving relative paths: `"config"` (relative to the config file) or `"cwd"` (relative to the current working directory). | | ||
|
|
||
| ```json | ||
| { | ||
| "input": ["./docs", "./guides"], | ||
| "output": "./test-results", | ||
| "recursive": true, | ||
| "relativePathBase": "config" |
There was a problem hiding this comment.
The relativePathBase option is documented here as accepting values "config" and "cwd" (with default "config"), but the schema reference at fern/pages/reference/schemas/config.md states accepted values are "cwd" and "file" (with default "file"). This inconsistency will mislead users — one of these sources is incorrect. The same discrepancy also exists in fern/pages/reference/api/resolve-paths.mdx (lines 44, 87, 95, 123) where "config" is used as a value.
| | `relativePathBase` | string | `"config"` | Base for resolving relative paths: `"config"` (relative to the config file) or `"cwd"` (relative to the current working directory). | | |
| ```json | |
| { | |
| "input": ["./docs", "./guides"], | |
| "output": "./test-results", | |
| "recursive": true, | |
| "relativePathBase": "config" | |
| | `relativePathBase` | string | `"file"` | Base for resolving relative paths: `"file"` (relative to the config file) or `"cwd"` (relative to the current working directory). | | |
| ```json | |
| { | |
| "input": ["./docs", "./guides"], | |
| "output": "./test-results", | |
| "recursive": true, | |
| "relativePathBase": "file" |
| "openApi": { | ||
| "server": "$API_SERVER" | ||
| } |
There was a problem hiding this comment.
The example at line 469 uses integrations.openApi as a plain object { "server": "$API_SERVER" }, but per the schema (and the correct example in integrations-options.md), openApi is an array of objects. This example will not validate against the schema and will mislead users about the correct format.
| "openApi": { | |
| "server": "$API_SERVER" | |
| } | |
| "openApi": [ | |
| { | |
| "server": "$API_SERVER" | |
| } | |
| ] |
| { | ||
| "record": { | ||
| "path": "results.mp4", | ||
| "directory": "static/media", | ||
| "overwrite": "true" | ||
| } | ||
| } |
There was a problem hiding this comment.
The record example at line 32-38 uses "overwrite": "true" (a string), which is consistent with the accepted values in record-detailed.md. However, "overwrite": "true" as a string is semantically confusing when users might expect a boolean. More importantly, the record field itself is typed as one of: string | object([Record (detailed)]) | boolean, but the example wraps the object form with "record": { ..., "overwrite": "true" } — this is consistent with the schema, so this is fine. However, overwrite for record only accepts "true" or "false" as strings, not the "aboveVariation" value that is used for screenshots and shell commands. Using "true" as a string is a potential confusion for users expecting a boolean true.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (4)
scripts/generate-references.ts (4)
90-92: Consider wrapping JSON.parse in try/catch for clearer error messages.If
schemas.jsonis malformed, the error will be a generic JSON parse error without context. Wrapping this in try/catch would provide a more actionable error message.Proposed improvement
-const allSchemas: Record<string, SchemaLike> = JSON.parse( - fs.readFileSync(SCHEMAS_JSON, "utf8") -); +let allSchemas: Record<string, SchemaLike>; +try { + allSchemas = JSON.parse(fs.readFileSync(SCHEMAS_JSON, "utf8")); +} catch (err) { + console.error(`Error parsing schemas from ${SCHEMAS_JSON}:`, err); + process.exit(1); +}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 90 - 92, Wrap the JSON.parse call that populates allSchemas (and the fs.readFileSync around it) in a try/catch to surface a clearer error message when SCHEMAS_JSON is malformed; in the catch include the SCHEMAS_JSON variable and the original parse error (e.g., `Error: failed to parse ${SCHEMAS_JSON}: ${err.message}`) and either rethrow or log and exit so the failure is obvious; update the code around JSON.parse(...) that assigns to allSchemas to implement this error handling.
242-254: Remove dead entry fordragAndDrop_v3fromdirectSchemas.The
dragAndDrop_v3entry at line 249 is immediately skipped at line 254 because it's already registered as a wrapper. This dead entry adds confusion.Proposed cleanup
const directSchemas: Array<{ key: string; file: string }> = [ { key: "config_v3", file: "config.md" }, { key: "context_v3", file: "context.md" }, { key: "test_v3", file: "test.md" }, { key: "spec_v3", file: "specification.md" }, { key: "openApi_v3", file: "openapi.md" }, - { key: "dragAndDrop_v3", file: "draganddrop.md" }, ]; for (const d of directSchemas) { - // dragAndDrop is already registered as a wrapper above, skip re-adding - if (d.file === "draganddrop.md") continue; const schema = get(d.key);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 242 - 254, The directSchemas array contains a dead entry { key: "dragAndDrop_v3", file: "draganddrop.md" } which is immediately skipped (see the if (d.file === "draganddrop.md") continue) because dragAndDrop is already registered as a wrapper; remove that object from the directSchemas array to eliminate the redundant entry and potential confusion, leaving directSchemas with only the actual direct schema entries (config_v3, context_v3, test_v3, spec_v3, openApi_v3).
1131-1140: Binding element type may be misleading when type is a reference.When the parameter type is a type reference (e.g.,
SomeOptions) rather than an inline type literal, each extracted binding element inherits the entire type name. This could produce misleading parameter tables where individual fields show the container type instead of their actual types.Consider using
"unknown"or attempting to resolve the referenced type.Proposed fix
} else { // Expand binding elements individually (type may be a reference or any) + // When type is a reference, we can't infer individual element types + const elementType = param.type && ts.isTypeReferenceNode(param.type) + ? "unknown" + : paramType; for (const element of param.name.elements) { if (ts.isBindingElement(element)) { const eName = element.name.getText(sourceFile); const eRequired = !element.dotDotDotToken && !element.initializer; - params.push({ name: eName, type: paramType, required: eRequired }); + params.push({ name: eName, type: elementType, required: eRequired }); } } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 1131 - 1140, The loop that expands binding elements (the block using param.name.elements, ts.isBindingElement, eName, eRequired, and params.push) incorrectly assigns the container paramType to each element when paramType is a TypeReference; change the logic to detect a referenced type (e.g., ts.isTypeReferenceNode(paramType)) and use "unknown" (or attempt to resolve via the typeChecker if available) as the element's type instead of the container name; compute elementType = ts.isTypeReferenceNode(paramType) ? "unknown" : paramType and push params.push({ name: eName, type: elementType, required: eRequired }) so individual fields no longer show the enclosing type reference.
977-979: Double backticks may not render complex defaults correctly.Using
``for complex JSON defaults may cause rendering issues in some markdown parsers. Consider using single backticks with proper escaping, or rendering complex defaults differently (e.g., omitting pipe characters in JSON).Alternative approach
// Complex defaults (arrays, objects) - return `\`\`${JSON.stringify(schema.default)}\`\``; + const json = JSON.stringify(schema.default).replace(/\|/g, "\\|"); + return `\`${json}\``;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generate-references.ts` around lines 977 - 979, The current return wraps JSON.stringify(schema.default) with inline double backticks which can break rendering for complex JSON; change the output to a fenced code block instead (e.g. use a triple-backtick block with "json" and pretty-printed JSON) by replacing the inline backtick expression around JSON.stringify(schema.default) with a multiline fenced block like ```json\n${JSON.stringify(schema.default, null, 2)}\n``` so complex defaults (including pipes/backticks) render correctly; locate the expression that returns ``\`\`${JSON.stringify(schema.default)}\`\`` and replace it with the fenced code block version.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@fern/pages/docs/config/configuration.mdx`:
- Line 482: Replace the bold-styled filename "**.doc-detective.ci.json**" with
inline code formatting so it reads `.doc-detective.ci.json`; locate the bold
token in the markdown content (the exact text "**.doc-detective.ci.json**") and
change the surrounding asterisks to backticks to render it in code font.
- Line 18: Update the terse link labels to descriptive, accessible phrases:
change the link text "`config`" to "config schema" (and similarly "`context`" →
"context schema", "`test`" → "test schema", "`specification`" → "specification
schema") in fern/pages/docs/config/configuration.mdx and the other occurrences
noted (around the blocks at 74-75 and 103-105); ensure the surrounding sentence
uses second person and active voice (e.g., "A JSON Schema is available at the
config schema for validation and autocompletion in your editor.") and keep
American spelling and friendly tone per the style guide.
- Around line 468-471: The snippet incorrectly shows integrations.openApi as an
object; update it to match the documented schema by making integrations.openApi
an array of objects and include the required descriptionPath field (e.g.,
"integrations": { "openApi": [ { "server": "$API_SERVER", "descriptionPath":
"<path/to/description>" } ] } ) so copy-pasting yields a valid config; locate
the example referencing integrations.openApi and replace the object form with
the array form including descriptionPath.
---
Nitpick comments:
In `@scripts/generate-references.ts`:
- Around line 90-92: Wrap the JSON.parse call that populates allSchemas (and the
fs.readFileSync around it) in a try/catch to surface a clearer error message
when SCHEMAS_JSON is malformed; in the catch include the SCHEMAS_JSON variable
and the original parse error (e.g., `Error: failed to parse ${SCHEMAS_JSON}:
${err.message}`) and either rethrow or log and exit so the failure is obvious;
update the code around JSON.parse(...) that assigns to allSchemas to implement
this error handling.
- Around line 242-254: The directSchemas array contains a dead entry { key:
"dragAndDrop_v3", file: "draganddrop.md" } which is immediately skipped (see the
if (d.file === "draganddrop.md") continue) because dragAndDrop is already
registered as a wrapper; remove that object from the directSchemas array to
eliminate the redundant entry and potential confusion, leaving directSchemas
with only the actual direct schema entries (config_v3, context_v3, test_v3,
spec_v3, openApi_v3).
- Around line 1131-1140: The loop that expands binding elements (the block using
param.name.elements, ts.isBindingElement, eName, eRequired, and params.push)
incorrectly assigns the container paramType to each element when paramType is a
TypeReference; change the logic to detect a referenced type (e.g.,
ts.isTypeReferenceNode(paramType)) and use "unknown" (or attempt to resolve via
the typeChecker if available) as the element's type instead of the container
name; compute elementType = ts.isTypeReferenceNode(paramType) ? "unknown" :
paramType and push params.push({ name: eName, type: elementType, required:
eRequired }) so individual fields no longer show the enclosing type reference.
- Around line 977-979: The current return wraps JSON.stringify(schema.default)
with inline double backticks which can break rendering for complex JSON; change
the output to a fenced code block instead (e.g. use a triple-backtick block with
"json" and pretty-printed JSON) by replacing the inline backtick expression
around JSON.stringify(schema.default) with a multiline fenced block like
```json\n${JSON.stringify(schema.default, null, 2)}\n``` so complex defaults
(including pipes/backticks) render correctly; locate the expression that returns
``\`\`${JSON.stringify(schema.default)}\`\`` and replace it with the fenced code
block version.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b41258b9-01a7-487c-9153-ce6732992a9b
📒 Files selected for processing (3)
fern/pages/docs/config/configuration.mdxfern/pages/docs/tests/overview.mdxscripts/generate-references.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- fern/pages/docs/tests/overview.mdx
| "integrations": { | ||
| "openApi": { | ||
| "server": "$API_SERVER" | ||
| } |
There was a problem hiding this comment.
Keep the openApi env-var example in the documented schema shape.
This snippet switches integrations.openApi back to an object, but the page defines it as an array of objects with descriptionPath a few sections earlier. Copy-pasting this example would give readers an invalid config.
💡 Proposed fix
"integrations": {
- "openApi": {
- "server": "$API_SERVER"
- }
+ "openApi": [
+ {
+ "descriptionPath": "./openapi.yaml",
+ "server": "$API_SERVER"
+ }
+ ]
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "integrations": { | |
| "openApi": { | |
| "server": "$API_SERVER" | |
| } | |
| "integrations": { | |
| "openApi": [ | |
| { | |
| "descriptionPath": "./openapi.yaml", | |
| "server": "$API_SERVER" | |
| } | |
| ] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fern/pages/docs/config/configuration.mdx` around lines 468 - 471, The snippet
incorrectly shows integrations.openApi as an object; update it to match the
documented schema by making integrations.openApi an array of objects and include
the required descriptionPath field (e.g., "integrations": { "openApi": [ {
"server": "$API_SERVER", "descriptionPath": "<path/to/description>" } ] } ) so
copy-pasting yields a valid config; locate the example referencing
integrations.openApi and replace the object form with the array form including
descriptionPath.
- ci.mdx: add missing script section to GitLab CI basic job example - configuration.mdx: fix relativePathBase default/values to 'file'/'cwd' matching schema; fix openApi env-var example to use array; fix schema link text to be descriptive; use code font for .doc-detective.ci.json filename - resolve-paths.mdx: fix relativePathBase examples and description text from 'config' to 'file' matching schema
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 68 out of 69 changed files in this pull request and generated 10 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|--------------| | ||
| | `{ fileURLOrPath }` | string | Yes | | |
There was a problem hiding this comment.
Same issue as in detect-tests.mdx: the parameter table entry { fileURLOrPath } includes the braces in the parameter name, which is confusing. The parameter name should be displayed as fileURLOrPath (noting that it's passed as a property of a single object argument).
| | `{ fileURLOrPath }` | string | Yes | | | |
| | `fileURLOrPath` | string | Yes | | |
| Field | Type | Description | Default | ||
| :-- | :-- | :-- | :-- | ||
| url | string | Required. URL to check. Can be a full URL or a path. If a path is provided, `origin` must be specified.<br/><br/>Pattern: `(^(http://|https://|/).*|\$[A-Za-z0-9_]+)` | | ||
| url | string | Required. URL to check. Can be a full URL or a path. If a path is provided, `origin` must be specified.<br/><br/>Pattern: `(^(http://|https://|/).*$|^\$[A-Za-z0-9_]+$)` | |
There was a problem hiding this comment.
The generate-references.ts script strips the leading ^ and trailing $ anchors from regex patterns for display (lines 941–942), yet the check-link-detailed.md file was manually edited to show the full anchored pattern (^(http://|https://|/).*$|^\$[A-Za-z0-9_]+$). This inconsistency means that when the generator is re-run, the anchor-stripping logic will produce a different output than what's currently in the file. Additionally, load-cookie-detailed.md and save-cookie-detailed.md currently show stripped patterns ([A-Za-z0-9_.-]+, [A-Za-z_][A-Za-z0-9_]*) while check-link-detailed.md retains them. The generator's pattern-stripping logic should be consistent, or the manual edits in check-link-detailed.md will be overwritten on the next run.
| url | string | Required. URL to check. Can be a full URL or a path. If a path is provided, `origin` must be specified.<br/><br/>Pattern: `(^(http://|https://|/).*$|^\$[A-Za-z0-9_]+$)` | | |
| url | string | Required. URL to check. Can be a full URL or a path. If a path is provided, `origin` must be specified.<br/><br/>Pattern: `((http://|https://|/).*$|\$[A-Za-z0-9_]+)` | |
| "window": {}, | ||
| "viewport": {} |
There was a problem hiding this comment.
The browser.md example was updated to use empty objects {} for window and viewport instead of showing actual field values. This makes the example less illustrative — readers won't know what fields to put inside those objects. The previous example (showing "width": 42, "height": 42) was more helpful. Consider keeping representative values or linking explicitly to the detailed sub-schema pages.
| "window": {}, | |
| "viewport": {} | |
| "window": { | |
| "width": 1280, | |
| "height": 720 | |
| }, | |
| "viewport": { | |
| "width": 1280, | |
| "height": 720 | |
| } |
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
The run-tests.mdx (and other API pages) have six blank lines between the {/* CUSTOM CONTENT START */} marker and the first section heading. This results in extra whitespace in the rendered page. This is cosmetic but worth cleaning up.
| if (schema.type === "object") { | ||
| if ( | ||
| schema.properties && | ||
| Object.keys(schema.properties).length === 0 && | ||
| schema.additionalProperties | ||
| ) { | ||
| return "object"; | ||
| } | ||
| return "object"; | ||
| } |
There was a problem hiding this comment.
The renderType function (lines 664–673) has two branches for schema.type === "object" that both return "object" — the inner condition checking empty properties with additionalProperties is redundant since both cases produce the same result. This makes the code harder to reason about.
| const config = { | ||
| input: "./docs", | ||
| fileTypes: [ | ||
| { | ||
| extensions: [".rst"], | ||
| testStartStatementOpen: ".. test:: ", | ||
| testStartStatementClose: "", | ||
| testEndStatement: ".. test-end::", | ||
| stepStatementOpen: ".. step:: ", | ||
| stepStatementClose: "", | ||
| }, | ||
| ], | ||
| }; |
There was a problem hiding this comment.
The "Custom file types" example in detect-tests.mdx uses properties (testStartStatementOpen, testStartStatementClose, testEndStatement, stepStatementOpen, stepStatementClose) that don't match the actual file-type-custom schema. According to the schema reference, the correct structure nests these patterns under inlineStatements, using testStart, testEnd, and step (not testStartStatementOpen, testEndStatement, stepStatementOpen, etc.). The example will not work as shown and should be updated to use the correct schema structure with inlineStatements.
|
|
||
| | Parameter | Type | Required | Description | | ||
| |-----------|------|----------|-------------| | ||
| | `{ config }` | any | Yes | | |
There was a problem hiding this comment.
Same issue as in detect-tests.mdx: the parameter name { config } includes braces. The parameter should be shown as config.
| | `{ config }` | any | Yes | | | |
| | `config` | any | Yes | | |
| path | string | Optional. File path to save the command's output, relative to `directory`. | | ||
| directory | string | Optional. Directory to save the command's output. If the directory doesn't exist, creates the directory. If not specified, the directory is your media directory. | | ||
| maxVariation | number | Optional. Allowed variation in percentage of text different between the current output and previously saved output. If the difference between the current output and the previous output is greater than `maxVariation`, the step fails. If output doesn't exist at `path`, this value is ignored.<br/><br/>Minimum: 0. Maximum: 1 | `0` | ||
| maxVariation | number | Optional. Allowed variation as a fraction (0 to 1) of text different between the current output and previously saved output. For example, 0.1 means 10%. If the difference between the current output and the previous output is greater than `maxVariation`, the step fails. If output doesn't exist at `path`, this value is ignored.<br/><br/>Minimum: 0. Maximum: 1<br/><br/>**Migration note:** Values are fractions, not percentages. If you previously used a percentage-style value like `10` (for 10%), update it to `0.1`. | `0` |
There was a problem hiding this comment.
The migration note added to the maxVariation field description in run-code-detailed.md and run-shell-command-detailed.md is helpful. However, embedding a migration note with bold Markdown (**Migration note:**) inside a table cell may not render correctly in all Markdown renderers (including some Fern Docs setups). If this is a known compatibility issue in this documentation framework, consider moving migration notes outside the table or using plain text.
| const allSchemas: Record<string, SchemaLike> = JSON.parse( | ||
| fs.readFileSync(SCHEMAS_JSON, "utf8") | ||
| ); |
There was a problem hiding this comment.
The generator script (generate-references.ts) uses module-level side effects: allSchemas is loaded via JSON.parse(fs.readFileSync(...)) and main() is called at the bottom of the file at module scope. If the SOURCE_REPO path check at line 24 fails, process.exit(1) is called, which is appropriate. However, there is no error handling around the JSON parse at lines 90–92 — if schemas.json is malformed or missing, the script will crash with an unhelpful stack trace rather than a descriptive error message. Consider wrapping the JSON parse in a try/catch with a helpful error message.
| { key: "dragAndDrop_v3", file: "draganddrop.md" }, | ||
| ]; | ||
|
|
||
| for (const d of directSchemas) { | ||
| // dragAndDrop is already registered as a wrapper above, skip re-adding | ||
| if (d.file === "draganddrop.md") continue; |
There was a problem hiding this comment.
The dragAndDrop_v3 schema is included in both actions (as a wrapper page) and directSchemas arrays. The continue guard on line 254 prevents double registration, but this is fragile. If someone removes the guard or adds a similar key in the future, the page will be registered twice with potentially different configurations, causing unpredictable output. A clearer approach would be to remove dragAndDrop_v3 from directSchemas entirely with a comment explaining why.
Add initial documentation structure and examples for various configurations and actions. This includes updates to JSON schemas and example usages to enhance clarity and usability.
Summary by CodeRabbit
Documentation
Chores