Repository navigation
build: serialize bundled guides one markdown line at a time - #33712
Conversation
|
No actionable comments were generated in the recent review.
|
|
Edits to separated Markdown payload lines could merge in the source guide but conflict in the committed embedded guide because each document occupied one generated source line. This PR gives each Markdown payload line its own source line, preserving the exported strings and existing generation/check workflow. App behavior is unchanged. Full-path review completed with correctness/every-consumer review, an independent architecture challenge, a dedicated performance pass, and the readiness checklist. No code fixes were required. Ordinary same/adjacent-line conflicts and folded-description metadata conflicts remain expected residual cases. The deferred concern is unmeasured cold-load/heap/compiler overhead from finite joins behind the existing lazy import; no repeated scaling work or demonstrated regression was found. Current-main integration: merge Verified after this merge: all exported records and 35 Markdown values (10 guides, 377,388 UTF-8 bytes) are identical to current main; generator --check passes. Combined SHA-256: Full PR workflow passed on merge head QA classification: qa=tests. Main merges preserve the existing QA evidence on For Brennan's review: no visual change. The judgments are the line encoding in serializeMarkdown and the existing generated-artifact lint treatment in oxlint. |
ELI5
Concurrent edits to different parts of the same skill guide can merge cleanly in Markdown but conflict in the committed generated file, because each whole guide occupies one source line. This change gives each Markdown line its own generated source line, reducing spurious conflicts for developers. App users see no change.
What Changed
The generator encodes guide, full-guide and reference Markdown as arrays of JSON-quoted lines joined with
\n. Splitting retains the trailing empty piece, so trailing newlines and all other runtime bytes stay identical. The committed output is regenerated, and its path joins the existing generated artifacts in the root oxlintignorePatternslist. No max-lines disable comment is added.The generator's
--checkmode and its CI invocation stay in place. The trackedskills/<name>/SKILL.mdcopies are unchanged.Why
A replay of the last 30 days of main found 15 conflicting pairs of guide commits, 13 caused only by the single-line generated strings. Two independent reviewers agreed that changing serialization is a better fit than moving generation to build time: that approach adds build prerequisites and maintenance that cost more than they save. The build-time proposal is being superseded by this narrower change, tracked in #30644.
Linked Issue
Tracked in #30644.
Visual Proof
N/A — generated source formatting only; runtime guide contents and UI are unchanged.
Testing
Loaded the original and regenerated TypeScript modules with Node and compared all exported guide records, then compared each Markdown value as UTF-8 buffers:
node config/scripts/generate-bundled-skill-guides.mjs --checkpassed after regeneration and formatting.node node_modules/vitest/vitest.mjs run --config config/vitest.config.ts config/scripts/generate-bundled-skill-guides.test.mjs src/cli/specs/bundled-guide-flags.test.ts— 2 files, 15 tests passed.git merge-filereplay changed the title and Screenshots heading independently in the same guide: the original generated file conflicted (exit 1); the regenerated file merged cleanly (exit 0).Review
Builder self-review completed. Independent lane review follows separately.
Agent skill upstream boundary
Notes
Serialization is platform-independent and preserves the existing LF bytes. There are no changes to SSH, mobile, saved data, build ordering, generated-file ownership or backwards compatibility. The generated module remains committed and requires no additional build step.
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)