Load `@octokit/plugin-paginate-rest` and [`@octokit/core`](https://github.com/octokit/core.js) (or core-compatible module) directly from [cdn.skypack.dev](https://cdn.skypack.dev)
The `paginateRest` plugin adds a new `octokit.paginate()` method which accepts the same parameters as [`octokit.request`](https://github.com/octokit/request.js#request). Only "List ..." endpoints such as [List issues for a repository](https://developer.github.com/v3/issues/#list-issues-for-a-repository) are supporting pagination. Their [response includes a Link header](https://developer.github.com/v3/issues/#response-1). For other endpoints, `octokit.paginate()` behaves the same as `octokit.request()`.
The `per_page` parameter is usually defaulting to `30`, and can be set to up to `100`, which helps retrieving a big amount of data without hitting the rate limits too soon.
An optional `mapFunction` can be passed to map each page response to a new value, usually an array with only the data you need. This can help to reduce memory usage, as only the relevant data has to be kept in memory until the pagination is complete.
Alternatively you can pass a `request` method as first argument. This is great when using in combination with [`@octokit/plugin-rest-endpoint-methods`](https://github.com/octokit/plugin-rest-endpoint-methods.js/):
Alternatively you can pass a `request` method as first argument. This is great when using in combination with [`@octokit/plugin-rest-endpoint-methods`](https://github.com/octokit/plugin-rest-endpoint-methods.js/):
```js
const parameters = {
owner: "octocat",
repo: "hello-world",
since: "2010-10-01",
per_page: 100,
};
for await (const response of octokit.paginate.iterator(
octokit.rest.issues.listForRepo,
parameters
)) {
// do whatever you want with each response, break out of the loop, etc.
const issues = response.data;
console.log("%d issues found", issues.length);
}
```
## `composePaginateRest` and `composePaginateRest.iterator`
The `compose*` methods work just like their `octokit.*` counterparts described above, with the differenct that both methods require an `octokit` instance to be passed as first argument
`octokit.paginate()` wraps `octokit.request()`. As long as a `rel="next"` link value is present in the response's `Link` header, it sends another request for that URL, and so on.
Most of GitHub's paginating REST API endpoints return an array, but there are a few exceptions which return an object with a key that includes the items array. For example:
The plugin also exposes some types and runtime type guards for TypeScript projects.
<table>
<tbodyvalign=topalign=left>
<tr><th>
Types
</th><td>
```typescript
import {
PaginateInterface,
PaginatingEndpoints,
} from "@octokit/plugin-paginate-rest";
```
</td></tr>
<tr><th>
Guards
</th><td>
```typescript
import { isPaginatingEndpoint } from "@octokit/plugin-paginate-rest";
```
</td></tr>
</tbody>
</table>
### PaginateInterface
An `interface` that declares all the overloads of the `.paginate` method.
### PaginatingEndpoints
An `interface` which describes all API endpoints supported by the plugin. Some overloads of `.paginate()` method and `composePaginateRest()` function depend on `PaginatingEndpoints`, using the `keyof PaginatingEndpoints` as a type for one of its arguments.
```typescript
import { Octokit } from "@octokit/core";
import {
PaginatingEndpoints,
composePaginateRest,
} from "@octokit/plugin-paginate-rest";
type DataType<T> = "data" extends keyof T ? T["data"] : unknown;
async function myPaginatePlugin<EextendskeyofPaginatingEndpoints>(
