Skip to content

Migrate to the schema-3 dependency set with documents.js 2.0.0 - #200

Merged
Mearman merged 3 commits into
mainfrom
feat/schema-3-dependency-set
Aug 17, 2026
Merged

Migrate to the schema-3 dependency set with documents.js 2.0.0#200
Mearman merged 3 commits into
mainfrom
feat/schema-3-dependency-set

Conversation

@Mearman

@Mearman Mearman commented Aug 17, 2026

Copy link
Copy Markdown
Member

documents.js 2.0.0 changed the DocumentPackage shape (the stored layout half is gone; per-node frames and package pages carry the geometry) and moved the whole family onto document-schema.js 3.x, where heading paragraphs carry headingLevel in the schema itself. This app holds documents.js, markdown-codec, and odf.js in one tree, so the single-package bump automation could never go green on it (sibling-update/documents.js-2.0.0 is red on Typecheck for exactly this reason) -- this is the one coordinated migration PR.

What changed:

  • Dependencies: documents.js ^1.102.2 -> ^2.0.0 (markdown-codec ^2.0.0 and odf.js ^3.0.1 were already in). The lockfile had document-schema.js 3.1.0 (via markdown-codec/odf.js) alongside 3.2.0 (via documents.js) after the bump; deduped so exactly one schema version (3.2.0) resolves across the whole tree.
  • Test fixtures: contentCounts.test.ts hardcoded formatVersion: 2; it now asserts the exported CONTENT_FORMAT_VERSION so it tracks the schema major instead of breaking on the next one.
  • Heading detection (src/rpc/router.ts): the app's heading-{N} styleId convention is now minted from ContentParagraph.headingLevel -- markdown-codec 2.0.0's lowering, ooxml.js's docx reader (w:outlineLvl through the style chain), and odf.js's odt reader (text:outline-level) all populate it. The docx/odt path keeps the Heading{N} styleId pattern as a fallback because the signals have different coverage: a style named Heading3 with no outline level is caught only by the pattern, and a custom style inheriting an outline level with a non-Heading name is caught only by the field. The markdown path drops parseHeadingStyleId entirely -- headingLevel is authoritative there.
  • xlsx content reads: documents.js 2.0.0 re-exports readXlsxContent, so the xlsx branch of readContentForFormat no longer detours through a full xlsx->ods bridge conversion to read .content off the result -- it uses the direct package reader like every other format, which also makes the function synchronous and drops its unused signal parameter.

The app never constructs a DocumentPackage or reads a stored .layout half itself (the pdf-inspect tool's LayoutDocument comes from readPdf, pdf-codec's own contract, which is unchanged), so the package-shape change needed no further code moves beyond the above.

Supersedes #199 (the automation's documents.js 2.0.0 bump PR, red on Typecheck).

Generated by Claude Code

documents.js 2.0.0 replaces the DocumentPackage layout half with
per-node frames and pages, and carries the whole family on
document-schema.js 3.x. The lockfile previously held schema 3.1.0
(via markdown-codec 2.0.0 / odf.js 3.0.1) and 3.2.0 (via
documents.js 2.0.0) side by side; deduped to a single 3.2.0. The
contentCounts test fixtures now assert CONTENT_FORMAT_VERSION
instead of the hardcoded literal 2 so they track the schema major.
…sx content directly

markdown-codec 2.0.0 lowerHeading and the docx/odt readers under
schema 3 all populate ContentParagraph.headingLevel, so the app's
heading-{N} convention is now minted from that field; the docx/odt
path keeps the Heading{N} styleId pattern as a fallback because the
two signals have different coverage (a style named Heading3 without
an outline level is caught only by the pattern; a custom style
inheriting an outline level is caught only by the field). The
markdown path drops parseHeadingStyleId entirely -- headingLevel is
authoritative there.

documents.js 2.0.0 re-exports readXlsxContent, so xlsx content
reads no longer detour through the xlsx->ods bridge conversion and
read .content off its result -- the direct package reader is used
like every other format, which also makes readContentForFormat
synchronous and drops its unused signal parameter.
The comment cited a normalizeWordprocessingHeadings function that
does not exist, and the rewrite now sources headingLevel rather
than only raw Heading{N} styleIds.
@Mearman
Mearman merged commit d0eaf30 into main Aug 17, 2026
7 checks passed
@Mearman
Mearman deleted the feat/schema-3-dependency-set branch August 17, 2026 16:35
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