Background
PR #2540 introduced a shared runOxfmt helper in scripts/generate-docs-content.ts that formats generated markdown via execFileSync("npx", ["oxfmt", ...]) with shell: process.platform === "win32", so the invocation also works on Windows. The final review of that PR noted one non-blocking (low) follow-up: scripts/generate-supported-tools-tables.ts still formats its generated tables with its own inline invocation, which predates the helper.
Details
scripts/generate-docs-content.ts:22 defines runOxfmt, including the Windows shell handling.scripts/generate-supported-tools-tables.ts:148 runs execFileSync("pnpm", ["exec", "oxfmt", ...targets.map((t) => t.path)], { stdio: "inherit" }) directly, without the Windows shell option and with a different runner (pnpm exec vs npx).
The two invocations do the same job (let oxfmt own the final markdown layout of generated files), so the duplication is a small drift risk: a future fix to one call site (e.g. the Windows handling) can silently miss the other.
Solution / Next Steps
- Extract
runOxfmt into a small shared module under scripts/ (e.g. alongside scripts/markdown-markers.ts) and accept one or more paths.
- Use it from both
generate-docs-content.ts and generate-supported-tools-tables.ts, unifying on a single runner and keeping the shell: process.platform === "win32" handling.
- Verify
pnpm run generate:tables and pnpm run generate:docs-content still produce byte-identical output (CI drift gates cover both).
Severity: low — cleanup only, no functional change expected.
Background
PR #2540 introduced a shared
runOxfmthelper inscripts/generate-docs-content.tsthat formats generated markdown viaexecFileSync("npx", ["oxfmt", ...])withshell: process.platform === "win32", so the invocation also works on Windows. The final review of that PR noted one non-blocking (low) follow-up:scripts/generate-supported-tools-tables.tsstill formats its generated tables with its own inline invocation, which predates the helper.Details
scripts/generate-docs-content.ts:22definesrunOxfmt, including the Windowsshellhandling.scripts/generate-supported-tools-tables.ts:148runsexecFileSync("pnpm", ["exec", "oxfmt", ...targets.map((t) => t.path)], { stdio: "inherit" })directly, without the Windowsshelloption and with a different runner (pnpm execvsnpx).The two invocations do the same job (let oxfmt own the final markdown layout of generated files), so the duplication is a small drift risk: a future fix to one call site (e.g. the Windows handling) can silently miss the other.
Solution / Next Steps
runOxfmtinto a small shared module underscripts/(e.g. alongsidescripts/markdown-markers.ts) and accept one or more paths.generate-docs-content.tsandgenerate-supported-tools-tables.ts, unifying on a single runner and keeping theshell: process.platform === "win32"handling.pnpm run generate:tablesandpnpm run generate:docs-contentstill produce byte-identical output (CI drift gates cover both).Severity: low — cleanup only, no functional change expected.