HAR-7108 - SuperDoc docx editor (super editor) package#3
Closed
harbournick wants to merge 3 commits intomainfrom
Closed
HAR-7108 - SuperDoc docx editor (super editor) package#3harbournick wants to merge 3 commits intomainfrom
harbournick wants to merge 3 commits intomainfrom
Conversation
tupizz
added a commit
that referenced
this pull request
Apr 16, 2026
…nt tests Applies testing-excellence principles to the SD-2563 test suite: 1. Remove dead mock stubs (Iron Law #3: never mock what you don't understand). 11 test files carried vi.mock('@superdoc/layout-resolved') stubs that no test depends on — PresentationEditor imports the module, but these tests don't exercise paths that call it. Verified by removing and running the full suite: all 11348 tests pass without the stubs. 2. Kept the stubs in 2 files whose tests genuinely depend on controlled resolveLayout behavior (PresentationEditor.footnotesPmMarkers and PresentationEditor.sectionPageStyles). 3. Added HeaderFooterSessionManager.alignment.test.ts covering the two previously-untested risk areas: - rId-based path delivers items aligned 1:1 with fragments (multi-section documents — uses real resolveHeaderFooterLayout) - Length-mismatch guard drops items and emits a warning when resolved and fragment counts diverge (proves the runtime safety net works) Net: -44 lines of dead mock boilerplate, +190 lines of real test coverage. Total super-editor tests: 11348 -> 11350.
4 tasks
tupizz
added a commit
that referenced
this pull request
Apr 23, 2026
… alignment tests (#2845) * refactor(painter): delete dead hash helpers after blockLookup removal * test(super-editor): remove dead layout-resolved mocks and add alignment tests Applies testing-excellence principles to the SD-2563 test suite: 1. Remove dead mock stubs (Iron Law #3: never mock what you don't understand). 11 test files carried vi.mock('@superdoc/layout-resolved') stubs that no test depends on — PresentationEditor imports the module, but these tests don't exercise paths that call it. Verified by removing and running the full suite: all 11348 tests pass without the stubs. 2. Kept the stubs in 2 files whose tests genuinely depend on controlled resolveLayout behavior (PresentationEditor.footnotesPmMarkers and PresentationEditor.sectionPageStyles). 3. Added HeaderFooterSessionManager.alignment.test.ts covering the two previously-untested risk areas: - rId-based path delivers items aligned 1:1 with fragments (multi-section documents — uses real resolveHeaderFooterLayout) - Length-mismatch guard drops items and emits a warning when resolved and fragment counts diverge (proves the runtime safety net works) Net: -44 lines of dead mock boilerplate, +190 lines of real test coverage. Total super-editor tests: 11348 -> 11350. * refactor(painter): remove legacy createDomPainter wrapper API The painter previously shipped a backward-compat API layer (setData, setResolvedLayout, paint(Layout) overload, blocks/measures constructor options, LegacyDomPainterState, buildLegacyPaintInput). This mixed-path logic existed only to smooth the migration to DomPainterInput. All production callers now use the modern contract directly. The benchmark is updated to call resolveLayout explicitly. Test call sites that still expressed fixtures as {blocks, measures} + raw Layout now route through a shared createTestPainter helper in painters/dom/src/test-utils/test-painter.ts, which wraps createDomPainter and runs resolveLayout internally. DomPainterOptions: blocks?/measures? removed DomPainterHandle: setData/setResolvedLayout removed, paint() takes only DomPainterInput Internal: LegacyDomPainterState, buildLegacyPaintInput, createEmptyResolvedLayout, isDomPainterInput, assertRequiredBlockMeasurePair all deleted. Closes SD-2563 criterion: painter does not carry mixed-path logic. No rendering change (layout-compare 0/407 changed). * test(pm-adapter): migrate integration tests off legacy painter API Luccas flagged on PR #2853 that three tests in pm-adapter/integration.test.ts were still using the deleted createDomPainter({blocks, measures}) + paint(Layout) pattern. My earlier audit missed this file because it scoped to painter-dom/src. Fix: each call site now constructs the DomPainterInput directly via resolveLayout(). Added @superdoc/layout-resolved to pm-adapter devDependencies. Verified: - pm-adapter: 1723/1723 tests pass (25 integration tests restored) - painter-dom: 952/952 - layout-resolved: 103/103 - layout-bridge: 1162/1162 - super-editor: 11350/11363 (13 pre-existing skipped) * [15/16] refactor(painter): provider callback receives ResolvedPage instead of Page (#2906) * refactor(painter): provider callback receives ResolvedPage instead of Page The PageDecorationProvider callback still received the legacy Page object even though every field it reads lives on ResolvedPage (lifted in PR 1). Change: - PageDecorationProvider 3rd arg: page?: Page -> resolvedPage?: ResolvedPage - renderer.ts passes resolvedPage (fallback: page.number/page.margins for bare numeric/margin args) - HeaderFooterSessionManager.createDecorationProvider reads from resolvedPage - #stripFootnoteReserveFromBottomMargin now takes resolvedPage - #computeExpectedSectionType now takes resolvedPage - rebuildRegions caches #currentResolvedLayout and maps pageIndex -> resolvedPage for both region construction and provider invocation - PresentationEditor threads resolvedLayout into updateDecorationProviders Addresses review comment on PR #2810 (Luccas): closes the last remaining legacy-Page dependency in the decoration provider path. No rendering change: layout-compare 0/407 against v.1.26.0-next.18 (same reference used throughout the stack). * refactor(painter): eliminate Page and sourceLayout from DomPainter (#2909) SD-2563 finale. The painter's input is now ResolvedLayout only. Design: - Each ResolvedPaintItem carries fragment: Fragment as a back-pointer, so render methods receive Fragment-shaped data without page.fragments iteration. - Outer loops iterate resolvedLayout.pages instead of layout.pages. - Page metadata reads (number, margins, size, numberText, footnoteReserved) all swapped to resolvedPage.X with no fallback. - DomPainterInput simplified to { resolvedLayout: ResolvedLayout }. - sourceLayout and all layout.X reads removed from the painter. Callers updated: PresentationEditor, test helpers, pm-adapter integration test. No rendering change: layout-compare 0/407 against v.1.26.0-next.18. --------- Co-authored-by: Nick Bernal <117235294+harbournick@users.noreply.github.com>
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
1 participant
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.
No description provided.