Fix getNextId to support variable-width numeric IDs#9
Conversation
getNextId was hardcoded to extract only the first 3 characters as the ID,
causing incorrect ID generation when filename_format uses wider IDs like
{{@id{4}}}. For example, with files 0001-foo.md and 0002-bar.md, the next
file would incorrectly be 0001-baz.md instead of 0003-baz.md.
Changed to extract all leading digits from filenames dynamically, making
it work correctly regardless of ID width.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug in the getNextId function that prevented it from correctly handling variable-width numeric IDs. Previously, the function hardcoded extraction of the first 3 characters, breaking support for formats like {{@id{4}}}.
Changes:
- Modified
getNextIdto dynamically extract all leading digits from filenames instead of hardcoding 3 characters - Removed zero-padding from returned ID values (now returns
"1"instead of"001") - Added comprehensive unit tests covering 3-digit, 4-digit, empty directory, and non-numeric filename scenarios
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| var dir = cwd.openDir(output_dir, .{ .iterate = true }) catch |err| { | ||
| if (err == error.FileNotFound) { | ||
| return try std.fmt.allocPrint(allocator, "{d:0>3}", .{1}); | ||
| return try std.fmt.allocPrint(allocator, "{d}", .{1}); |
There was a problem hiding this comment.
The function now returns unpadded ID strings (e.g., '1' instead of '001'), which may break existing code that expects zero-padded IDs. Consider whether the calling code handles formatting separately, or if padding width should be determined from existing files in the directory.
| } | ||
|
|
||
| return try std.fmt.allocPrint(allocator, "{d:0>3}", .{max_id + 1}); | ||
| return try std.fmt.allocPrint(allocator, "{d}", .{max_id + 1}); |
There was a problem hiding this comment.
The function now returns unpadded ID strings, which differs from the previous zero-padded format. This may break existing code that expects zero-padded IDs. Consider whether the calling code handles formatting separately, or if padding width should be determined from existing files in the directory.
1 participant
Summary
getNextId()always extracted the first 3 characters as the ID, causing incorrect ID generation for formats like{{@id{4}}}getNextIdcovering 3-digit, 4-digit, empty directory, and non-numeric filename casesTest plan
zig build test{{@id{4}}}format and existing0001-foo.md,0002-bar.md, runningdraft adr "baz"generates0003-baz.md{{@id}}(3-digit) format continues to work as expected🤖 Generated with Claude Code