Documentation

• #579

Features

• could it be pageable for searching - #562
• Organisation.listMembers returns max 30 members #509
• Commits, statuses, etc. after first page are not included in results #507
• search is get all result, cause 403 error - #460
• list all gists - #458
• Cannot fetch all milestones - #441
• Pulling all contributors of a repo - #421
• [Feature Request] Ability to fetch a single page of items in a list - #406 (includes lots of good discussion)
• pagination in listIssueComments - #398 (PR)

Bugs

• _requestAllPages pagination is broken - #569
• listBranches() does not return all branches in a repository - #592

Some of these issues are likely outdated.

Our goal will be to have a standardized paging methodology that all functions make use of. Part of the problem right now is that some functions use _requestAllPages and some don't.

If we want to maintain backwards compatibility for our current 3.x.x release, I'm proposing that we default to _requestAllPages, but allow options to be passed in that includes per_page and page.

If we have time, having async-based pagination would be really slick.

There seem to be a lot of pagination-related issues. I'm happy to try to help get this sorted but I might need a bit of help/guidance because I don't know the codebase.

Yes this is the primary issue with the library right now. The big thing we'd need is standardization. Every function call in our library that hits a GitHub endpoint that allows paging should allow for our users to pass through something like:

{
  per_page: 15,
  page: 3
}

In terms of guidance, I'll try to put together a PR with an example of the direction I'm thinking of going in.

I'd like to add that orgainsation.getRepos( only returns first 100 repositories.