[JasonColapietro]

Summary

Fixes #198 — a <table> nested directly inside an <li> was silently dropped from the DOCX.

classifyListItemChildren() buckets <table> as a block element (LIST_ITEM_BLOCK_TAGS). The block branch pushes the vNode onto the list queue, and when it was popped the buildList loop sent it into xmlBuilder.buildParagraph() — which has no way to translate a table vNode into a paragraph, so it emitted nothing.

The failure mode is the bad kind: the wrapper paragraphs render, the surrounding list items render, the file is well-formed OOXML and opens cleanly in Word and LibreOffice. The table is just gone. Nothing warns the caller.

Change

buildList() now detects a <table> vNode and routes it through xmlBuilder.buildTable(), using the same options as the top-level <table> branch of findXMLEquivalent() (maximumWidth, rowCantSplit, and the table.addSpacingAfter trailing paragraph). A table renders the same way whether or not it sits inside a list.

Word has no concept of a table carrying a bullet or number marker, so the table renders between the list item's paragraphs — matching the direction suggested in the issue (option 1).

29 lines in src/helpers/render-document-file.js. No change to xml-builder.js.

Result

Input from the issue:

<ul>
  <li>
    <p>before table</p>
    <table border="1">
      <tr><td>r1c1</td><td>r1c2</td></tr>
      <tr><td>r2c1</td><td>r2c2</td></tr>
    </table>
    <p>after table</p>
  </li>
  <li>second item</li>
</ul>

Reading the generated .docx back with mammoth (an independent DOCX reader, not this library):

Before — no table, no cells:

<ul><li>before table</li></ul><p>after table</p><ul><li>second item</li></ul>

After — all four cells present, in source order:

<ul><li>before table</li></ul><table><tr><td><p>r1c1</p></td><td><p>r1c2</p></td></tr><tr><td><p>r2c1</p></td><td><p>r2c2</p></td></tr></table><p>after table</p><ul><li>second item</li></ul>

Tests

The known-limitation test in tests/list-multiple-paragraphs.test.js ('<table> inside <li> does not crash and preserves wrapper paragraphs', which documented the drop and invited a future fix to flip it) now asserts the table renders.

A new Tables inside list items - Issue #198 suite covers:

• the exact issue reproduction — <w:tbl> present, 4 <w:tc>, all cell text
• source ordering — table sits between the wrapper paragraphs
• a table as an <li>'s only child
• tables in nested <ol>/<ul> without disturbing numbering (numbering-definition count and following-item order asserted)
• <thead>/<tbody> rows
• the table.addSpacingAfter option honored on this path

All 7 fail on develop and pass with the fix.

Verification

Command	Result
npx jest	624 passed, 20 suites, 0 failed
npm run build	exit 0
node example/example-node.js	exit 0 (Docx file created successfully)
npx eslint src/helpers/render-document-file.js	0 problems, unchanged from develop
npx prettier --check on changed files	4 pre-existing warnings in the test file, identical count before and after

Also checked: every XML part of the generated package parses, and the document body still ends with a paragraph rather than a table (OOXML requires a table to be followed by one) — including when the table is the last content in the document.

Scope notes

Two related things I deliberately left alone, happy to follow up if you'd like them:

• Indentation. A table inside a list item renders at the same width and alignment as a top-level table rather than indenting to line up with the item's continuation paragraphs. Indenting means emitting w:tblInd, and the correct ECMA-376 CT_TblPrBase position for it is between w:tblCellSpacing and w:tblBorders — but buildTableProperties() currently emits w:tblPr children in Object.keys() order, so placing it correctly means sequencing that element list. Given fix: sort <w:rPr> children to ECMA-376 EG_RPrBase spec order #202 (sorting w:rPr children to spec order) landed for exactly this class of bug, that felt like it deserves its own PR rather than riding along here.
• <table></table> with no rows produces an empty <w:tbl>. That is pre-existing and identical on the top-level table path — this change neither introduces nor fixes it.

[github-actions]

TurboDocx DOCX Diff Report

Automated HTML to DOCX regression testing | Powered by TurboDocx

Summary

• ✅ Identical files: 71
• 🔄 Changed files: 0
• ➕ New files: 0
• ➖ Deleted files: 0

---

🚀 Powered by TurboDocx | html-to-docx

Automated DOCX regression testing • Catch document generation bugs before they ship • 100% open source

Generated by TurboDocx DOCX Diff workflow • Learn more

[nicolasiscoding]

@JasonColapietro !! 1909 friend thanks

[JasonColapietro]

Thanks Nicolas! One heads-up in case it saves you a step: the Test PR and CodeQL workflows are waiting on first-time-contributor approval, so only the docx-diff check ran automatically.

To de-risk the merge, I pulled current develop (eab9490) into the branch locally — clean merge, and npm run test:all is fully green: 21/21 suites, 641/641 tests, plus the example/TS/RTL generation steps. Happy to rebase or adjust anything if useful.

[nicolasiscoding]

@JasonColapietro sorry for this last minute, if you can, go into the examples folder https://github.com/TurboDocx/html-to-docx/tree/develop/example and add examples where you deem appropriate for this but need a few outside of the unit tests

[JasonColapietro]

@nicolasiscoding Examples added — example/example-table-in-list.js covers a <table> inside a <ul>, inside an <ol>, and inside a nested list, plus the table.addSpacingAfter option so the spacing behaviour is visible too. I also rebased onto current develop so this picks up #225 and #231.

One thing worth flagging separately: docx-diff is currently failing on every PR in the repo, not just this one. It isn't detecting a real output change.

b69dd31 (#225) added a guard to scripts/diff-docx.js:

Output path must be within the current working directory

but .github/workflows/docx-diff.yml still invokes it as:

node scripts/diff-docx.js ../baseline.docx ../current.docx --output ../diff-report.md

../diff-report.md is outside the working directory, so the script exits non-zero, the workflow sets diff_failed=true, and the verify step reports the misleading "DOCX diff detected unexpected changes."

Evidence:

• I generated baseline (develop) and current (this branch) DOCX with DETERMINISTIC_IDS=true npm test and ran your diff script with an in-tree output path. Result: 71 identical files, 0 changed, 0 new, 0 deleted — this PR does not alter example-node.docx at all.
• bugfix/dependabot-security-patches-2026-08 failed the same check three times on 2026-08-24, and every docx-diff run before 2026-08-23 succeeded.

Two ways to fix it, whichever you prefer:

1. Write the report inside the working directory and adjust the later steps, e.g. --output diff-report.md run from the repo root.
2. Keep the guard but resolve --output against process.cwd() before the containment check, so a path that stays inside the runner workspace is allowed.

Happy to open a separate PR for that if it's useful — I left it out of this one to keep the change focused.

[nicolasiscoding]

you rock, if you can open the other PR would be super helpful then rebase it into this change

[JasonColapietro]

Done — the CI repair is now in #233 and ready for review, and I rebased this branch onto that repair as requested. The stack is now current with develop through #232. Fresh local validation on the combined history is green: 22/22 suites, 645/645 tests, all build/example/TypeScript/RTL generation steps, and example/example-table-in-list.js itself. The existing docx-diff check may remain red until #233 lands because the current pull_request_target event loads the workflow from develop; after #233 merges, the next synchronization of this PR will use the corrected workflow.

[JasonColapietro]

Rebased onto current develop (571d2e4). Since #233's CI repair is superseded by your docx-diff rework in 5250db8 and 297adee, I dropped that commit from this stack. This PR is now just the two list/table commits.

Fresh local validation on 29bcef2: 21/21 Jest suites (642/642 tests), npm test (build + node example), example/example-table-in-list.js, and ESLint on the changed source/example files.

[K-Kumar-01]

Thanks @JasonColapietro for this PR.
Looks good to me.
Tested locally and the Pr is working.
Attached the files below

example-table-in-list_after.docx
example-table-inside-list_before.docx

Just one suggestion:

"test:example-table": "npm run build && node example/example-table-in-list.js",

Can we add the above script in package.json?

[JasonColapietro]

Thanks for the review and for testing it locally, @K-Kumar-01. Added the test:example-table script to package.json in 0501a43. It runs npm run build && node example/example-table-in-list.js, and I confirmed it builds and generates the docx.

[K-Kumar-01]

Merging it @nicolasiscoding