Proposal
In v6, flip the default of GenericIncluder's orderBy option to 'natural' (currently unset → no sort).
Motivation
#1871 reports that numerically-named docs (1.md, 2.md, …, 20.md, 100.md) appear in nonsensical order when using GenericIncluder, because the includer historically had // TODO: implement sort and emitted items in glob/FS + JS object key order.
#1901 adds opt-in orderBy: 'natural' | 'filename' and order: 'asc' | 'desc' options. Setting orderBy: 'natural' resolves the issue today, but the default still produces the bad order out of the box.
Flipping the default is a behavior change observable to every existing GenericIncluder user: their generated TOCs will reorder on upgrade. This kind of default flip is exactly what v6 is for, similar to #1900 (linkIndexAutotitle default flip).
Acceptance criteria
Related
Proposal
In v6, flip the default of
GenericIncluder'sorderByoption to'natural'(currently unset → no sort).Motivation
#1871 reports that numerically-named docs (
1.md,2.md, …,20.md,100.md) appear in nonsensical order when usingGenericIncluder, because the includer historically had// TODO: implement sortand emitted items inglob/FS + JS object key order.#1901 adds opt-in
orderBy: 'natural' | 'filename'andorder: 'asc' | 'desc'options. SettingorderBy: 'natural'resolves the issue today, but the default still produces the bad order out of the box.Flipping the default is a behavior change observable to every existing
GenericIncluderuser: their generated TOCs will reorder on upgrade. This kind of default flip is exactly what v6 is for, similar to #1900 (linkIndexAutotitledefault flip).Acceptance criteria
orderBybecomes'natural'Related