Initial checklist
Affected package
mdast-util-gfm 3.1.0, mdast-util-gfm-table (via mdast-util-gfm), mdast-util-to-markdown 2.1.2
Steps to reproduce
Parsing a GFM table with rows of unequal cell counts, then stringifying and
re-parsing, changes the tableRow cell counts to match the header width.
round-trips through structure:
tree1: table > [row(cells=2), row(cells=1)]
tree2: table > [row(cells=2), row(cells=2)]
parse
tree₁:
{
"type": "table",
"children": [
{ "type": "tableRow", "children": [
{ "type": "tableCell", "children": [{ "type": "text" }] },
{ "type": "tableCell", "children": [] }
]},
{ "type": "tableRow", "children": [
{ "type": "tableCell", "children": [] }
]}
]
}
stringify it:
tree₂ has two cells in the second body row (padded to header width):
{
"type": "table",
"children": [
{ "type": "tableRow", "children": [
{ "type": "tableCell", "children": [{ "type": "text" }] },
{ "type": "tableCell", "children": [] }
]},
{ "type": "tableRow", "children": [
{ "type": "tableCell", "children": [] },
{ "type": "tableCell", "children": [] }
]}
]
}
Two other fixtures in micromark-extension-gfm-table's suite minimize to the
same shape (||\n-|\n|||, ||||||\n-|-|-|-|-\n|) with the same signature.
📓 GFM §4.10 says short rows render as padded. The AST preserves real
widths though, and the serializer emits them padded, so a re-parse sees the
padded widths and the tree structure drifts. Either (a) the parser should
normalize row widths to header width at parse time, or (b) the serializer
should not pad short rows. Round-trip stability requires picking one.
Actual behavior
Short body rows are padded to match the header width on stringify, so the
re-parsed tree has more cells than the original.
Expected behavior
parse → stringify → parse preserves tableRow cell counts.
Runtime
No response
Package manager
No response
Operating system
No response
Build and bundle tools
No response
Initial checklist
Affected package
mdast-util-gfm 3.1.0, mdast-util-gfm-table (via mdast-util-gfm), mdast-util-to-markdown 2.1.2
Steps to reproduce
Parsing a GFM table with rows of unequal cell counts, then stringifying and
re-parsing, changes the
tableRowcell counts to match the header width.round-trips through structure:
parse
tree₁:
{ "type": "table", "children": [ { "type": "tableRow", "children": [ { "type": "tableCell", "children": [{ "type": "text" }] }, { "type": "tableCell", "children": [] } ]}, { "type": "tableRow", "children": [ { "type": "tableCell", "children": [] } ]} ] }stringify it:
tree₂ has two cells in the second body row (padded to header width):
{ "type": "table", "children": [ { "type": "tableRow", "children": [ { "type": "tableCell", "children": [{ "type": "text" }] }, { "type": "tableCell", "children": [] } ]}, { "type": "tableRow", "children": [ { "type": "tableCell", "children": [] }, { "type": "tableCell", "children": [] } ]} ] }Two other fixtures in micromark-extension-gfm-table's suite minimize to the
same shape (
||\n-|\n|||,||||||\n-|-|-|-|-\n|) with the same signature.📓 GFM §4.10 says short rows render as padded. The AST preserves real
widths though, and the serializer emits them padded, so a re-parse sees the
padded widths and the tree structure drifts. Either (a) the parser should
normalize row widths to header width at parse time, or (b) the serializer
should not pad short rows. Round-trip stability requires picking one.
Actual behavior
Short body rows are padded to match the header width on stringify, so the
re-parsed tree has more cells than the original.
Expected behavior
parse → stringify → parsepreserves tableRow cell counts.Runtime
No response
Package manager
No response
Operating system
No response
Build and bundle tools
No response