docs: make the 1.0.0 changelog readable rather than dense - #503
Merged
Merged
Conversation
Now that the GitHub release is the CHANGELOG entry, how the entry reads is how the release reads, and the 1.0.0 entry was a wall of text: tight lists with no blank lines between items, several bullets running to eight lines, and two that carried three paragraphs each. Nothing anchored the eye — no tables, no code blocks, no subheadings between the section headers. Same facts, restructured. The two multi-paragraph bullets become subsections, so INode and listProps are navigable rather than buried mid-list. An at-a-glance table near the top carries the four numbers most readers want. The merge order for listProps becomes a table, since it was a three-way precedence rule written as prose. Both upgrade steps become code blocks showing the before and after, which is shorter than describing the edit and harder to misread. Lists are loose throughout, so items separate instead of running together. Checked that nothing was lost by grepping the rewritten section for every term the original used, and that the code fences and tables are balanced. The live v1.0.0 release has been updated with the result. Co-Authored-By: Claude Opus 5 <noreply@anthropic.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
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.
The live v1.0.0 release is already updated with the result. This PR brings
CHANGELOG.mdin line, since #502 made the release be the CHANGELOG entry — which means how the entry reads is how the release reads.What was wrong
The 1.0.0 entry was a wall of text:
INode,listProps), buried mid-list with no heading to find them by141 lines of unbroken prose bullets.
Same facts, restructured
####subsectionsINodeandlistPropsare navigable instead of buriedlistPropsmerge order becomes a tableNow 181 lines with 2 tables, 2 code blocks and 4 subsections, so the section headers aren't the only structure.
Nothing lost
I grepped the rewritten section for every term the original used —
20,000-level,object-hash,IRenderedNode,listProps,TOP_LEVEL,paddingLeftIncrement,node-view,keyExtractor,IRow,initialNumToRender,_internalId,readonly INode— all still present, and the code fences and table header rows are balanced.Also fixed a stray blank line that had made one item of the Fixed list render as a separate list.
Note for next time
prettier-checkonly coverssrc/**/*.{ts,tsx}, so Markdown is unformatted and hand-aligned tables survive as written. That is what we want here, but worth knowing the CHANGELOG has no automated formatting behind it.🤖 Generated with Claude Code