- How do I install knplabs/github-api in a Laravel application?
- Install it with Composer using knplabs/github-api:^3.0 plus a PSR-18 client and a PSR-17 factory, for example guzzlehttp/guzzle:^7.0.1 and http-interop/http-factory-guzzle:^1.0. Most Laravel apps already ship Guzzle and guzzlehttp/psr7, which satisfy those interfaces, so discovery usually works without extra config. Build the client explicitly in a service provider with Client::createWithHttpClient() and bind it (or a gateway interface wrapping it) into the container so jobs and controllers get a single configured instance.
- Does knplabs/github-api work with Laravel and which Laravel versions are supported?
- The package is framework-agnostic and requires only PHP 7.2 or newer plus PSR-17 and PSR-18 implementations, so it runs on any current Laravel release that meets those requirements. It is not a Laravel package itself and ships no service provider, facade, or config file. For a Laravel-shaped wrapper with a facade and published config you can use graham-campbell/github, which depends on this library and is maintained by one of the same maintainers.
- Should I use Guzzle or Symfony HttpClient with knplabs/github-api?
- Either works, because the library is decoupled from the transport through HTTPlug and only needs PSR-17/PSR-18 implementations. Guzzle 7 plus guzzlehttp/psr7 is the shortest path in a typical Laravel app and lets you add retry, logging, and metrics as middleware. Symfony HttpClient with nyholm/psr7 is a good fit if you prefer its HttplugClient adapter or already standardise on Symfony components. Whichever you choose, construct the client explicitly rather than relying on implicit discovery, so a slim production image can't fall back to a missing factory.
- How do I call the GitHub GraphQL API v4 with this package?
- The client exposes a GraphQL API alongside the REST v3 endpoint classes, so you can send a query string plus variables through the same authenticated client instance. Use GraphQL when you need cross-repository reporting or nested data that would otherwise cost many paginated REST calls against your rate limit. For newly released REST endpoints that are not yet covered by a dedicated API class, drop down to the generic get(), post(), or graphql() escape hatches instead of waiting for a release.
- How do I test code that uses knplabs/github-api in Laravel?
- Laravel's Http::fake() does not intercept this client, because it speaks PSR-18 rather than Illuminate\Http\Client. Either inject a mock PSR-18 client such as php-http/mock-client into the real Github\Client, or wrap the library behind your own GitHubGateway contract and fake that in tests. The second approach is usually cleaner and keeps endpoint classes, ResultPager, and exception types out of your controllers and jobs.
- How should I authenticate knplabs/github-api: personal access token or GitHub App?
- A personal access token is the fastest option: pass it to the client's authenticate() method and you are done, but it is tied to a person and coarsely scoped. GitHub App installation tokens are least-privilege and give higher per-installation rate limits, but they expire after one hour, so token acquisition and refresh must be a cached, injectable concern. If you run long-lived queue workers with Horizon, never cache a client instance with a baked-in token, since it will start failing silently once the token expires.
- How do I handle pagination and GitHub rate limits with this client?
- Use the built-in ResultPager, which wraps the client and walks paginated responses with fetch() and fetchAll() so you don't hand-roll Link header parsing. Rate limits are a transport and design concern: cache responses where possible, prefer conditional requests with ETags, and reach for GraphQL when REST pagination across many repositories would burn through your quota. Retry, backoff, and circuit breaking are not provided, so add them as Guzzle middleware, a Symfony client decorator, or Laravel job middleware.
- Is knplabs/github-api the same as graham-campbell/github, and which one should I use in Laravel?
- They are different packages: knplabs/github-api is the underlying PHP client, while graham-campbell/github is a Laravel wrapper that depends on it and adds a facade, a published config file, and a manager pattern. The wrapper removes boilerplate for straightforward CRUD, but it introduces a second version axis and upgrade cadence. For anything beyond simple calls, consuming knplabs/github-api directly behind your own interface usually gives you more control.
- Can I use knplabs/github-api with GitHub Enterprise Server or a custom base URL?
- Yes. The client can be pointed at an Enterprise base URL instead of the public api.github.com host, so REST and GraphQL requests go to your own instance. That matters if you are targeting GitHub Enterprise Server rather than github.com, or if you route through a proxy. Verify the GraphQL endpoint configuration as well, because it is a separate URL from the REST base on Enterprise.
- Is knplabs/github-api actively maintained and safe to depend on in production?
- It is a long-standing, extensively tested MIT-licensed library, but maintenance is concentrated in a small number of named maintainers, so bus factor is the main risk rather than functionality. The practical mitigation is to wrap it behind your own gateway contract bound in a service provider, which keeps endpoint classes and exception types out of your domain code and makes swapping to raw Guzzle cheap. Also expect some lag on brand-new GitHub endpoints, pin your Composer constraint, and budget time for using the generic request methods when an endpoint is not yet covered.