Migrate to the schema-3 dependency set with documents.js 2.0.0 - #200
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
documents.js 2.0.0 changed the DocumentPackage shape (the stored
layouthalf is gone; per-nodeframesand packagepagescarry the geometry) and moved the whole family onto document-schema.js 3.x, where heading paragraphs carryheadingLevelin 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.0is red on Typecheck for exactly this reason) -- this is the one coordinated migration PR.What changed:
^1.102.2->^2.0.0(markdown-codec^2.0.0and odf.js^3.0.1were 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.contentCounts.test.tshardcodedformatVersion: 2; it now asserts the exportedCONTENT_FORMAT_VERSIONso it tracks the schema major instead of breaking on the next one.src/rpc/router.ts): the app'sheading-{N}styleId convention is now minted fromContentParagraph.headingLevel-- markdown-codec 2.0.0's lowering, ooxml.js's docx reader (w:outlineLvlthrough the style chain), and odf.js's odt reader (text:outline-level) all populate it. The docx/odt path keeps theHeading{N}styleId pattern as a fallback because the signals have different coverage: a style namedHeading3with 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 dropsparseHeadingStyleIdentirely --headingLevelis authoritative there.readXlsxContent, so the xlsx branch ofreadContentForFormatno longer detours through a full xlsx->ods bridge conversion to read.contentoff the result -- it uses the direct package reader like every other format, which also makes the function synchronous and drops its unusedsignalparameter.The app never constructs a
DocumentPackageor reads a stored.layouthalf itself (the pdf-inspect tool'sLayoutDocumentcomes fromreadPdf, 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