Add start offset pagination to search command#188
Conversation
pchuri
left a comment
pchuri
left a comment
There was a problem hiding this comment.
Thanks for picking this up — --start has been a missing piece for search, and the change is pleasantly small. I appreciate that you offset the displayed numbering (${start + index + 1}), updated the README, and added coverage for both the client param and the CLI help.
One required change inline before this can land. The rest of my notes (test coverage for negative --start, using the existing parsePositiveInt helper in the client, showing Showing N–M of TOTAL) are nice-to-haves and can be follow-ups.
| .option('--start <start>', 'Start index for results', '0') | ||
| .option('--cql', 'Pass query as raw CQL instead of text search') | ||
| .action(withClient('search', async ({ client, analytics }, query, options) => { | ||
| const results = await client.search(query, parseInt(options.limit), options.cql); | ||
| const limit = parseInt(options.limit, 10); |
There was a problem hiding this comment.
Required before merge: this introduces a behavior change that's outside the stated scope of the PR.
Previously parseInt(options.limit) happily passed NaN or 0 through to the API; now search --limit 0 and search --limit abc throw. That's probably the right tightening, but it's unrelated to adding --start, so please pick one of:
- Call this out in the PR description and CHANGELOG so users know
--limit <= 0now errors, or - Drop the
limitvalidation from this PR and submit it separately, leaving the--startchange minimal.
Either is fine — I just don't want the limit change to slip in silently under a PR titled "Add start offset pagination".
Expose the Confluence REST search start offset through the search command so users can request later pages of results. Validate the start value at the CLI layer, pass it through the client, and keep displayed result numbering aligned with the requested offset. Add coverage for both the client request parameter and the CLI help output.
barrylv123
force-pushed
the
feat/search-start-pagination
branch
from
993a8c0 to
065766b
Compare
pchuri
left a comment
pchuri
left a comment
There was a problem hiding this comment.
Thanks for the quick turnaround — scoping the PR down to just --start is exactly what I was after. Diff is clean, tests cover the new param, and the offset numbering is a nice touch.
The follow-up items from the earlier review (negative-value tests for --start, using the existing parsePositiveInt helper in the client, surfacing Showing N–M of TOTAL in the output) are all non-blocking and can land separately if you're interested. LGTM 🚀
# [2.7.0](v2.6.3...v2.7.0) (2026-05-18) ### Features * **search:** add start offset pagination ([#188](#188)) ([f8c73bd](f8c73bd))
|
🎉 This PR is included in version 2.7.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
3 participants
Summary
Adds a
--startoption to thesearchcommand so users can request later pages of Confluence search results.Changes
startthrough to the Confluence REST search API.--startas a non-negative number at the CLI layer.Testing
npx jest --runInBand --no-watchman tests/cli-entry.test.js tests/confluence-client.test.jsnpm run lint -- bin/confluence.js lib/confluence-client.js tests/cli-entry.test.js tests/confluence-client.test.js