@octokit/core

@octokit/core is the minimal, extendable client at the heart of the Octokit ecosystem for calling GitHub’s REST and GraphQL APIs. It bundles authentication, request signing, and hook-based middleware into a single Octokit class that can be extended with plugins and defaults, letting teams build a custom Octokit tailored to exactly the endpoints and behavior they need rather than pulling in the full, heavier octokit package.

Beyond just making requests, it standardizes how the wider Octokit family (REST plugins, GraphQL, authentication strategies, pagination) compose together, which is why it underpins most GitHub Apps, Actions, and automation tooling written in JavaScript/TypeScript.

What You Get

• A minimal Octokit class supporting both REST (octokit.request()) and GraphQL (octokit.graphql()) calls out of the box
• A plugin system (Octokit.plugin()) for composing additional functionality like the full REST endpoint methods, pagination, or throttling
• Built-in authentication support via @octokit/auth-token and pluggable custom auth strategies (Apps, OAuth, installation tokens)
• A hooks API (before, after, error, request) for intercepting and modifying every request/response
• Runs in Node.js and browsers, with first-class TypeScript types generated from the OpenAPI-derived Octokit spec

Common Use Cases

• Building a custom, minimal GitHub API client with only the plugins and auth strategy a project actually needs
• Powering GitHub Apps and Actions that need authenticated REST/GraphQL access to repositories, issues, and pull requests
• Writing CI/automation scripts that query or mutate GitHub data (labels, releases, workflow runs) via a consistent client
• Composing custom Octokit distributions as a base for internal SDKs or tools by layering project-specific plugins on top of core

Under The Hood

Architecture - src/index.ts defines the Octokit base class: its constructor wires up hooks (via before-after-hook), an auth strategy, and default request options, then exposes request (delegating to @octokit/request) and graphql (delegating to @octokit/graphql) as bound methods; the static Octokit.plugin() method returns a new subclass with additional instance properties/methods mixed in, which is how the rest of the Octokit ecosystem (REST endpoint methods, pagination, retry, throttling) is layered on without bloating the core.

Tech Stack - Pure TypeScript, published as an ESM module ("type": "module"), depending on sibling Octokit packages (@octokit/auth-token, @octokit/graphql, @octokit/request, @octokit/request-error) rather than reimplementing HTTP/auth logic; the build pipeline uses a custom scripts/build.mjs plus tsc, and tests run under Vitest with coverage, alongside a dedicated test:typescript step that type-checks example usage under strict compiler options.

Code Quality - The core module itself is deliberately small (three files: index.ts, types.ts, version.ts), pushing complexity out to well-tested sibling packages and plugins, which keeps the surface area easy to reason about; the test:typescript validation step is a notable quality practice, catching type-level regressions in consumer-facing generics that unit tests alone would miss.

API Design - The plugin-composition pattern (Octokit.plugin(pluginA, pluginB)) is the standout ergonomic choice: it lets consumers opt into exactly the functionality they need (e.g. skip REST endpoint sugar if they only need GraphQL) while keeping a single, consistent Octokit mental model across the whole ecosystem, at the cost of needing to understand the plugin/hook system to extend behavior.