Skip to content

ci: statically check doc code blocks on every PR#70

Open
Sednaoui wants to merge 2 commits into
mainfrom
ci/docs-code-check
Open

ci: statically check doc code blocks on every PR#70
Sednaoui wants to merge 2 commits into
mainfrom
ci/docs-code-check

Conversation

@Sednaoui

@Sednaoui Sednaoui commented Jul 3, 2026

Copy link
Copy Markdown
Member

What

Tier-1 docs CI, as discussed: static verification only, nothing executes, no network, no keys, zero impact on the shipped site (all new packages are devDependencies used only by the checker).

  • scripts/check-docs-code.mjs extracts every ```json and ```ts/typescript/tsx block under docs/ (627 today). JSON must JSON.parse; TypeScript must pass tsc --noEmit against the pinned abstractionkit@0.4.0, with ethers, viem, wagmi, dotenv, siwe, and safe-recovery-service-sdk resolvable.
  • Two-pass tsc: a single syntax error anywhere makes tsc skip semantic checking for the entire program, so pass 1 catches syntax failures and pass 2 re-checks the clean blocks for semantic errors (renamed methods, wrong fields, undefined variables). Verified with a synthetic bad block: TS2339 Property 'thisMethodDoesNotExist' does not exist on type 'SafeMultiChainSigAccountV1'.
  • Baseline ratchet: the 448 pre-existing failures (mostly intentionally elided excerpts and JSON with placeholders) live in scripts/docs-check-baseline.json, keyed by content hash. CI fails only on new failures. Editing a baselined block changes its hash, so it must then pass, be fixed, or get an explicit <!-- docs-check: skip --> marker. Coverage ratchets up as pages are touched.
  • .github/workflows/docs-check.yml runs the checker plus yarn build (broken-link check) on every PR and on main.
  • yarn check-docs runs it locally; --update-baseline rewrites the baseline.

Numbers

627 blocks checked: 179 pass today, 448 baselined, 0 new. The baselined set is the to-do list for making pages self-contained, which is what the agent-consumability review called for anyway.

Verification

yarn check-docs exits 0; the synthetic semantic-error test fails it as expected; yarn build still passes.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features
    • Added automated documentation code-block validation in CI for pull requests and pushes to the main branch.
    • Code snippets labeled as JSON/TypeScript/TSX in docs are now statically checked during the docs/build process.
  • Bug Fixes
    • Improved detection and reporting of invalid JSON and TypeScript examples within documentation.
  • Chores
    • Added a docs-check script and maintained a baseline file for known doc snippet failures, plus updated required project tooling.

Extracts every json and ts/tsx fenced block from docs/ and verifies it
without executing anything: JSON blocks must parse, TypeScript blocks
must typecheck against the pinned abstractionkit@0.4.0 (plus ethers,
viem, wagmi, dotenv, siwe, safe-recovery-service-sdk as devDependencies;
nothing ships to the site bundle).

tsc runs in two passes because a single syntax error anywhere makes it
skip semantic checking for the whole program.

Pre-existing failures (448 of 627 blocks, mostly intentionally elided
excerpts) are recorded in a baseline keyed by content hash: CI fails
only on new failures, and editing a baselined block re-checks it. An
inline <!-- docs-check: skip --> marker exempts intentional elisions.

The workflow also runs yarn build on PRs, which catches broken links.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 3, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
developer-docs Ready Ready Preview, Comment Jul 3, 2026 1:51pm

Request Review

@coderabbitai

coderabbitai Bot commented Jul 3, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6bc4ac56-5493-4f21-ae0b-c1ca153ce007

📥 Commits

Reviewing files that changed from the base of the PR and between 67a9f29 and 5004389.

📒 Files selected for processing (1)
  • .github/workflows/docs-check.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/docs-check.yml

📝 Walkthrough

Walkthrough

This PR adds a docs code-block checker, a baseline of known failures, npm wiring for the checker, and a GitHub Actions workflow that runs the checker and build on pull requests and pushes to main.

Changes

Documentation Code Verification

Layer / File(s) Summary
Fence extraction, hashing, and skip handling
scripts/check-docs-code.mjs
Sets up docs walking, fenced block extraction for json/ts/tsx, line tracking, skip markers, and stable block hashing.
Validation execution: JSON parsing and two-pass tsc checks
scripts/check-docs-code.mjs
Validates JSON blocks with JSON.parse and TS/TSX blocks through scratch files and a two-pass tsc flow that maps diagnostics back to doc lines.
Baseline comparison, reporting, and exit behavior
scripts/check-docs-code.mjs, scripts/docs-check-baseline.json
Compares current failures with the baseline, detects stale entries, supports baseline updates, prints results, and exits nonzero on new failures.
npm script wiring, dependencies, and CI workflow
package.json, .github/workflows/docs-check.yml
Adds the check-docs script, expands devDependencies, and adds a workflow that runs docs checks and build on PRs and main pushes.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHub Actions
  participant check-docs-code.mjs
  participant tsc
  participant docs-check-baseline.json

  GitHub Actions->>check-docs-code.mjs: yarn check-docs
  check-docs-code.mjs->>check-docs-code.mjs: extract fenced blocks
  check-docs-code.mjs->>check-docs-code.mjs: hash and validate JSON blocks
  check-docs-code.mjs->>tsc: pass1 syntax check for ts/tsx scratch files
  tsc-->>check-docs-code.mjs: syntax diagnostics
  check-docs-code.mjs->>tsc: pass2 semantic check on clean files
  tsc-->>check-docs-code.mjs: semantic diagnostics
  check-docs-code.mjs->>docs-check-baseline.json: load known-failure hashes
  check-docs-code.mjs->>check-docs-code.mjs: compare current and baseline failures
  check-docs-code.mjs-->>GitHub Actions: report summary and exit code
  GitHub Actions->>GitHub Actions: yarn build
Loading

Poem

A rabbit checked the docs by light,
With hashes tucked in snug and tight.
JSON parsed, TS took a run,
Baselines hummed, “new failures? none.”
Hop, hop—clean code feels bright.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the main change: adding a CI job to statically check documentation code blocks on PRs.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

Comment @coderabbitai help to get the list of available commands.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/docs-check.yml (1)

1-32: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Add an explicit permissions block (least privilege).

Both jobs run with the default GITHUB_TOKEN permissions since no top-level or job-level permissions: is declared, flagged by static analysis as excessive-permissions. Neither job needs anything beyond read access to repo contents.

🔒 Proposed fix
 name: docs-check
 
+permissions:
+  contents: read
+
 on:
   pull_request:
   push:
     branches: [main]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/docs-check.yml around lines 1 - 32, Add an explicit
least-privilege permissions setting for this workflow so both the code-blocks
and build jobs don’t inherit the default broad GITHUB_TOKEN scope. Update the
docs-check workflow by adding a top-level permissions block, or equivalent
job-level permissions on code-blocks and build, limited to read access for
repository contents. Use the workflow jobs and triggers already defined in
docs-check.yml to place the restriction without changing the existing steps.

Source: Linters/SAST tools

🧹 Nitpick comments (3)
.github/workflows/docs-check.yml (1)

8-31: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low value

Consider a concurrency group to cancel superseded runs.

Both jobs run on every pull_request sync and push to main; without a concurrency block, superseded pushes to the same PR branch will queue redundant yarn install + typecheck runs.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/docs-check.yml around lines 8 - 31, Add a workflow-level
concurrency group to the docs-check workflow so older runs are canceled when a
new push/sync arrives. Update the workflow containing the code-blocks and build
jobs to use a stable group key based on the branch or PR ref, and enable
cancel-in-progress so superseded runs do not keep executing redundant yarn
install and validation steps.
scripts/check-docs-code.mjs (2)

180-186: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Baseline key order isn't deterministic.

next[f.hash] is inserted in failures iteration order, which follows filesystem traversal order (fs.readdirSync), not a stable sort. Re-running --update-baseline in a different environment/OS can reorder the whole ~390-entry file, producing noisy diffs unrelated to actual failure changes.

♻️ Proposed fix
 if (updateBaseline) {
   const next = {};
   for (const f of failures) next[f.hash] = `${f.file}:${f.line} (${f.lang})`;
-  fs.writeFileSync(baselinePath, JSON.stringify(next, null, 2) + "\n");
+  const sorted = Object.fromEntries(Object.keys(next).sort().map((k) => [k, next[k]]));
+  fs.writeFileSync(baselinePath, JSON.stringify(sorted, null, 2) + "\n");
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/check-docs-code.mjs` around lines 180 - 186, The baseline rewrite in
updateBaseline is producing nondeterministic key order because next is populated
directly from failures iteration order. Update the baseline generation path in
scripts/check-docs-code.mjs so failures are sorted by a stable key before
building next, or otherwise ensure deterministic insertion order before
fs.writeFileSync writes baselinePath. Use the updateBaseline block and the
failures collection as the place to apply the stable ordering.

150-171: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Second tsc pass runs even when pass 1 found zero syntax errors.

cleanFiles is "all files not present in pass1's error map," so on the common all-clean run (no syntax errors anywhere), pass1 already contains full semantic diagnostics (per the comment, semantic checking is only globally suppressed when a syntax error exists), yet cleanFiles ends up including essentially the entire block set and pass2 recompiles it all again for no new information. With ~300+ baselined TS blocks, this doubles tsc runtime on every "healthy" CI run.

⚡ Proposed fix
   const pass1 = runTsc(tsBlocks.map((b) => b.scratchFile), "tsconfig.json");
+  const hasSyntaxErrors = [...pass1.values()].some((diags) =>
+    diags.some((d) => /^error TS1\d{3}:/.test(d.message))
+  );
   const cleanFiles = tsBlocks.map((b) => b.scratchFile).filter((f) => !pass1.has(f));
-  const pass2 = cleanFiles.length > 0 ? runTsc(cleanFiles, "tsconfig-pass2.json") : new Map();
+  const pass2 = hasSyntaxErrors && cleanFiles.length > 0 ? runTsc(cleanFiles, "tsconfig-pass2.json") : new Map();
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/check-docs-code.mjs` around lines 150 - 171, The two-pass logic in
runTsc is recompiling all clean TypeScript blocks even when pass1 found no
syntax errors, which doubles runtime on healthy runs. Update the tsBlocks
handling so pass2 only runs when pass1 actually reports at least one
syntax-error file, and keep using pass1 diagnostics directly when there are no
syntax failures. Use the existing runTsc, pass1, pass2, and cleanFiles flow to
gate the second compilation more tightly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/docs-check.yml:
- Line 13: Set persist-credentials to false on each actions/checkout@v4 step in
the docs workflow so the GITHUB_TOKEN is not stored in the workspace. Update
both checkout invocations in the workflow jobs, since neither job needs to push
or reuse credentials, and keep the fix scoped to the checkout action
configuration.

In `@package.json`:
- Around line 34-43: The docs typecheck is using a mismatched Node API surface
because package.json pins `@types/node` to a newer major than the Node version
used by the docs-check workflow. Update the `@types/node` dependency in
package.json to match the CI Node runtime, or adjust the docs-check workflow to
run on the same Node major; use the `@types/node` entry and the docs-check
workflow as the two places to keep aligned.

In `@scripts/check-docs-code.mjs`:
- Around line 110-148: The runTsc helper is currently swallowing failed tsc/npx
executions when no parseable TS errors are emitted, causing an empty Map to be
treated as success. Update runTsc so that the execFileSync failure path in the
try/catch for npx tsc cannot silently return no errors: capture the thrown error
state and rethrow or otherwise signal a hard failure if output contains no
matched TS diagnostics. Keep the change localized to runTsc and its output
parsing logic so callers no longer treat invocation failures as passing.

---

Outside diff comments:
In @.github/workflows/docs-check.yml:
- Around line 1-32: Add an explicit least-privilege permissions setting for this
workflow so both the code-blocks and build jobs don’t inherit the default broad
GITHUB_TOKEN scope. Update the docs-check workflow by adding a top-level
permissions block, or equivalent job-level permissions on code-blocks and build,
limited to read access for repository contents. Use the workflow jobs and
triggers already defined in docs-check.yml to place the restriction without
changing the existing steps.

---

Nitpick comments:
In @.github/workflows/docs-check.yml:
- Around line 8-31: Add a workflow-level concurrency group to the docs-check
workflow so older runs are canceled when a new push/sync arrives. Update the
workflow containing the code-blocks and build jobs to use a stable group key
based on the branch or PR ref, and enable cancel-in-progress so superseded runs
do not keep executing redundant yarn install and validation steps.

In `@scripts/check-docs-code.mjs`:
- Around line 180-186: The baseline rewrite in updateBaseline is producing
nondeterministic key order because next is populated directly from failures
iteration order. Update the baseline generation path in
scripts/check-docs-code.mjs so failures are sorted by a stable key before
building next, or otherwise ensure deterministic insertion order before
fs.writeFileSync writes baselinePath. Use the updateBaseline block and the
failures collection as the place to apply the stable ordering.
- Around line 150-171: The two-pass logic in runTsc is recompiling all clean
TypeScript blocks even when pass1 found no syntax errors, which doubles runtime
on healthy runs. Update the tsBlocks handling so pass2 only runs when pass1
actually reports at least one syntax-error file, and keep using pass1
diagnostics directly when there are no syntax failures. Use the existing runTsc,
pass1, pass2, and cleanFiles flow to gate the second compilation more tightly.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 149f3f5e-4c12-4396-b2e7-fa00c64e766a

📥 Commits

Reviewing files that changed from the base of the PR and between 8ac20ad and 67a9f29.

⛔ Files ignored due to path filters (1)
  • yarn.lock is excluded by !**/yarn.lock, !**/*.lock
📒 Files selected for processing (4)
  • .github/workflows/docs-check.yml
  • package.json
  • scripts/check-docs-code.mjs
  • scripts/docs-check-baseline.json

name: Check doc code blocks
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Set persist-credentials: false on checkout steps.

Both actions/checkout@v4 steps default to persisting the GITHUB_TOKEN credential in the workspace, which is unnecessary here since neither job pushes or authenticates further. Flagged by zizmor as credential persistence (artipacked).

🔒 Proposed fix
       - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
       - uses: actions/setup-node@v4

Also applies to: 25-25

🧰 Tools
🪛 zizmor (1.26.1)

[warning] 13-13: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/docs-check.yml at line 13, Set persist-credentials to
false on each actions/checkout@v4 step in the docs workflow so the GITHUB_TOKEN
is not stored in the workspace. Update both checkout invocations in the workflow
jobs, since neither job needs to push or reuse credentials, and keep the fix
scoped to the checkout action configuration.

Source: Linters/SAST tools

Comment thread package.json
Comment on lines +34 to +43
"@types/node": "^26.1.0",
"abstractionkit": "0.4.0",
"dotenv": "^17.4.2",
"ethers": "^6.17.0",
"safe-recovery-service-sdk": "^0.0.4",
"siwe": "^3.0.0",
"tailwindcss": "^4.3.1",
"typescript": "^6.0.3"
"typescript": "^6.0.3",
"viem": "^2.54.2",
"wagmi": "^3.6.21"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Do @types/node major version mismatches with the Node.js runtime cause type errors with commonly used Node APIs?

💡 Result:

Yes, major version mismatches between @types/node and the Node.js runtime can cause type errors, primarily due to how TypeScript handles global declarations [1][2]. When multiple packages in a project (or its dependencies) rely on different versions of @types/node, it often results in duplicate declarations of global objects (such as AbortSignal, Buffer, or global Node.js APIs) [3][1][2]. Because TypeScript does not support multiple conflicting declarations for the same global variable, this leads to the common TS2403 error (Subsequent variable declarations must have the same type) [1][2]. The implications of a mismatch generally fall into two categories: 1. Build-Time Type Errors: If your project or its dependencies use incompatible versions, you may encounter compilation failures because the global type definitions provided by @types/node clash [3][2]. This is frequently solved by aligning all dependencies to the same major version of @types/node [3][1]. 2. Inaccurate Type Checking: - If @types/node is older than your runtime, TypeScript will not recognize newer Node.js APIs, leading to compilation errors when you use them [4]. - If @types/node is newer than your runtime, TypeScript might permit the use of APIs that are not actually available in your current Node.js environment, which can lead to runtime crashes when the code is executed [4]. To maintain stability, it is recommended to match the major version of @types/node to the major version of the Node.js environment being used [4]. In complex projects, ensure that sub-dependencies do not pull in conflicting versions of @types/node, often by using resolutions (in npm/yarn) or overrides to enforce a single version [3].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== package.json ==\n'
cat -n package.json | sed -n '1,140p'

printf '\n== docs-check workflow ==\n'
cat -n .github/workflows/docs-check.yml | sed -n '1,120p'

printf '\n== search for node/version references ==\n'
rg -n --hidden --glob '!**/node_modules/**' 'setup-node|node-version|`@types/node`|engines' .github package.json

Repository: candidelabs/developer-docs

Length of output: 3760


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== tsconfig files ==\n'
fd -a 'tsconfig*.json' .

printf '\n== docs-check script ==\n'
cat -n scripts/check-docs-code.mjs | sed -n '1,260p'

printf '\n== tsconfig / type references ==\n'
rg -n --hidden --glob '!**/node_modules/**' '"types"|`@types/node`|node:' tsconfig*.json . scripts package.json .github/workflows

Repository: candidelabs/developer-docs

Length of output: 12515


Align @types/node with the CI Node version. package.json pins @types/node to ^26.1.0, but .github/workflows/docs-check.yml runs the docs typecheck on Node 22. That makes the docs checker use a newer API surface than CI actually provides; either pin @types/node to 22 or bump the workflow to 26.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@package.json` around lines 34 - 43, The docs typecheck is using a mismatched
Node API surface because package.json pins `@types/node` to a newer major than the
Node version used by the docs-check workflow. Update the `@types/node` dependency
in package.json to match the CI Node runtime, or adjust the docs-check workflow
to run on the same Node major; use the `@types/node` entry and the docs-check
workflow as the two places to keep aligned.

Comment on lines +110 to +148
function runTsc(files, configName) {
const tsconfig = {
compilerOptions: {
target: "ES2022",
module: "ESNext",
moduleResolution: "Bundler",
jsx: "react-jsx",
lib: ["ES2022", "DOM"],
types: ["node"],
strict: false,
noEmit: true,
skipLibCheck: true,
esModuleInterop: true,
},
files,
};
const configPath = path.join(tmpDir, configName);
fs.writeFileSync(configPath, JSON.stringify(tsconfig, null, 2));
let output = "";
try {
execFileSync("npx", ["tsc", "-p", configPath, "--pretty", "false"], {
cwd: repoRoot,
encoding: "utf8",
maxBuffer: 64 * 1024 * 1024,
});
} catch (err) {
output = `${err.stdout ?? ""}${err.stderr ?? ""}`;
}
const errors = new Map(); // scratchFile -> [{ line, message }]
for (const line of output.split("\n")) {
const m = line.match(/^(.*?)\((\d+),(\d+)\): (error TS\d+: .*)$/);
if (!m) continue;
const file = path.resolve(repoRoot, m[1]);
const entry = errors.get(file) ?? [];
entry.push({ line: Number(m[2]), message: m[4] });
errors.set(file, entry);
}
return errors;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== scripts/check-docs-code.mjs (relevant section) ==\n'
nl -ba scripts/check-docs-code.mjs | sed -n '1,220p'

printf '\n== package.json / lockfile references to typescript, npx, and node typings ==\n'
for f in package.json npm-shrinkwrap.json package-lock.json pnpm-lock.yaml yarn.lock; do
  if [ -f "$f" ]; then
    echo "--- $f ---"
    rg -n '"typescript"|`@types/node`|npx|tsc' "$f" || true
  fi
done

Repository: candidelabs/developer-docs

Length of output: 258


🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== scripts/check-docs-code.mjs (relevant section) ==\n'
cat -n scripts/check-docs-code.mjs | sed -n '1,220p'

printf '\n== package.json ==\n'
cat -n package.json | sed -n '1,260p'

printf '\n== lockfile references to typescript / `@types/node` ==\n'
for f in package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock; do
  if [ -f "$f" ]; then
    echo "--- $f ---"
    rg -n '"typescript"|`@types/node`|typescript@|`@types/node`@' "$f" || true
  fi
done

Repository: candidelabs/developer-docs

Length of output: 13102


Fail closed when tsc invocation fails scripts/check-docs-code.mjs:110-148 — if npx/tsc exits before emitting error TS... lines, runTsc returns an empty map and the caller treats every TS block as passing. Surface that as a hard error instead.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/check-docs-code.mjs` around lines 110 - 148, The runTsc helper is
currently swallowing failed tsc/npx executions when no parseable TS errors are
emitted, causing an empty Map to be treated as success. Update runTsc so that
the execFileSync failure path in the try/catch for npx tsc cannot silently
return no errors: capture the thrown error state and rethrow or otherwise signal
a hard failure if output contains no matched TS diagnostics. Keep the change
localized to runTsc and its output parsing logic so callers no longer treat
invocation failures as passing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant