GO — Healthy across all four use cases

• Last commit 4d ago
• MIT licensed
• CI configured
• Tests present
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

Got is a lightweight, human-friendly HTTP client library for Node.js that abstracts away Node's native http/https modules with a simpler API. It supports HTTP/1.1, HTTP/2, automatic retries, pagination, request/response hooks, caching via cacheable-request, and modern features like stream composition—all built in TypeScript and exported as ESM-only. TypeScript monolith under source/ with core logic split into source/as-promise/index.ts and source/core, exporting a single main entry via source/index.js. Compiled to dist/source for distribution. Documentation lives in documentation/ (guides like 2-options.md, 4-pagination.md) with runnable examples in documentation/examples/. Benchmarks and tests are integrated, not separate packages.

Node.js backend developers and CLI tool authors who need a more intuitive HTTP client than the built-in http module, similar to what curl/wget provide but with programmatic control, retry logic, and TypeScript support.

Highly mature and production-ready. Currently at v15.0.5 with continuous active development (indexed via GitHub workflows in .github/workflows/main.yml), comprehensive test suite run via ava, TypeScript strict checking, and detailed documentation across 10+ markdown guides. The README explicitly notes v11 is no longer maintained, showing disciplined versioning.

Low risk. Maintained by a single high-profile author (Sindresorhus) with strong community support (GitHub sponsors noted in funding.yml), stable dependency graph (13 core dependencies, all version-locked in package.json), and Node.js >=22 requirement keeps the codebase modern. However, dependent on one maintainer for releases; breaking changes between major versions (evident from v11 EOL notice) require attention.

Active development with Node.js 22+ requirement and recent dependency updates (type-fest@5.6.0, @types/node@25.6.0 visible). The project maintains strict TypeScript checking (tsc --noEmit in test script) and no breaking API changes visible in recent version jumps, suggesting focus on refinement and bug fixes rather than major restructuring.

git clone https://github.com/sindresorhus/got.git && cd got && npm install && npm test

Daily commands: npm test (runs linting, TypeScript check, and ava test suite with tsx/esm loader). npm run build compiles TypeScript to dist/. npm run test:coverage adds c8 code coverage.

• source/index.ts — Main entry point exporting the Got HTTP client instance and create factory; every contributor must understand the public API surface.
• source/core/index.ts — Core request handler implementing the request lifecycle, retry logic, hooks, and response processing; the heart of Got's functionality.
• source/as-promise/index.ts — Promise-based API wrapper that converts the stream-based core into a user-friendly async/await interface.
• source/types.ts — TypeScript type definitions for options, responses, and client API; critical for understanding the public contract.
• source/core/options.ts — Options normalization and merging logic that transforms user input into internal request configuration.
• source/create.ts — Factory for creating Got instances with custom defaults; enables extension and composition patterns.

• Core Handler (source/core/index.ts) (Node.js http/https, EventEmitter, Streams, timers) — Manages the entire request lifecycle: initialization, hooks, retry logic, timeout handling, response assembly, and error propagation
  • Failure mode: Network error, timeout, or bad response status → throws GotError subclass; unhandled rejection crashes process
• Options Normalizer (source/core/options.ts) (TypeScript, deep object merging) — Transforms user-supplied options into normalized internal configuration; merges defaults and validates constraints
  • Failure mode: Invalid option values → throws TypeError synchronously before request starts
• Promise Wrapper (source/as-promise/index.ts) — Converts stream-based core into promise/async

Add a new hook type

1. Define the hook signature in source/types.ts under Hooks type (source/types.ts)
2. Emit the hook in the appropriate lifecycle point in source/core/index.ts (source/core/index.ts)
3. Add test cases in test/hooks.ts to verify hook invocation (test/hooks.ts)

Add a retry condition or backoff strategy

1. Extend RetryOptions interface in source/types.ts (source/types.ts)
2. Update retry logic in source/core/index.ts to check the new condition (source/core/index.ts)
3. Modify backoff calculation in source/core/calculate-retry-delay.ts if needed (source/core/calculate-retry-delay.ts)
4. Add test cases in test/error.ts covering the new retry scenario (test/error.ts)

Add a new option parameter

1. Add the option to Options interface in source/types.ts (source/types.ts)
2. Handle normalization and defaults in source/core/options.ts (source/core/options.ts)
3. Use the option in request handling in source/core/index.ts (source/core/index.ts)
4. Add test coverage in appropriate test file (e.g., test/http.ts or test/arguments.ts) (test/arguments.ts)

Add custom error handling

1. Define new error class extending GotError in source/core/errors.ts (source/core/errors.ts)
2. Throw the error from source/core/index.ts at the appropriate point in request lifecycle (source/core/index.ts)
3. Add error detection tests in test/error.ts (test/error.ts)

• TypeScript — Enables type-safe HTTP client API with full IntelliSense; critical for developer experience in a library
• Node.js http/https modules — Provides low-level control over HTTP requests, streaming, and connection pooling without external dependencies
• Stream-based architecture — Enables efficient handling of large payloads and piping; foundation for backpressure support and memory efficiency
• diagnostics_channel — Non-intrusive observability hook for tracing and monitoring without vendor lock-in

• Promise-first API wrapping stream-based core

  • Why: Provides ergonomic async/await interface while maintaining efficient streaming under the hood
  • Consequence: Requires buffering response bodies in memory unless user explicitly uses stream mode; adds abstraction layer

• No built-in authentication/cookie handling in core

  • Why: Keeps core lightweight and composable; plugins/middleware can add auth layers
  • Consequence: Users must implement auth manually or use extensions; slightly more boilerplate than frameworks like axios

• Node.js 22+ only (moving away from browser support)

  • Why: Simplifies maintenance and enables modern JavaScript features (ESM, top-level await)
  • Consequence: Not usable in browsers; users must find alternatives for frontend HTTP

• Synchronous options normalization before async request

  • Why: Catch configuration errors early and provide fast failure feedback
  • Consequence: Options validation happens inline; no lazy loading of defaults

• Browser HTTP client (Node.js only)
• Built-in authentication mechanisms (delegates to plugins/middleware)
• GraphQL client (generic HTTP library, not query-language specific)
• Request body validation (responsibility of application layer)

ESM-only codebase with no CommonJS export (npm won't warn users converting from v14+); requires Node.js >=22 (tsx/esm loader needed for test execution). The .npmrc file is present but not shown—check it for registry/auth quirks. Tests use NODE_OPTIONS='--import=tsx/esm' to run TypeScript directly; standard node test runners won't work. Benchmark server (benchmark/server.ts) must be running separately for benchmark/index.ts; no automatic setup evident.

• HTTP/2 Server Push & Multiplexing — Got's http2-wrapper dependency handles protocol negotiation and multiplexing; understanding when HTTP/2 is used vs HTTP/1.1 is key to debugging performance and stream behavior
• Request/Response Hooks & Interceptors — documentation/9-hooks.md outlines beforeRequest, afterResponse, beforeRetry lifecycle hooks; essential for implementing auth, logging, or custom request transformation without subclassing
• Automatic Retry with Exponential Backoff — documentation/7-retry.md shows Got's built-in retry strategy with configurable delays; central to reliability in production HTTP clients
• Response Caching via Cache-Control Headers — cacheable-request dependency intercepts responses and respects HTTP cache directives; Got's cache option in documentation/cache.md leverages this to reduce redundant requests
• Stream Composition & Pipe Chains — documentation/3-streams.md shows how Got returns Node streams that can be piped; critical for handling large payloads and avoiding memory bloat
• Pagination Cursors & Link Headers — documentation/4-pagination.md demonstrates automatic pagination following RFC 8288 Link headers; Got abstracts iteration over large result sets
• Diagnostics Channel for Observability — documentation/diagnostics-channel.md shows integration with Node.js native diagnostics for tracing requests without modifying Got code; important for APM and debugging

• sindresorhus/ky — Official alternative by same author; browser-compatible, fetch-based HTTP client for modern isomorphic apps
• axios/axios — Direct competitor; universal HTTP client for Node.js and browser with similar retry/interceptor/promise API
• node-fetch/node-fetch — Lighter-weight Node.js fetch polyfill; Got wraps native http/https whereas node-fetch emulates browser Fetch
• sindresorhus/fetch-extras — Minimal companion by same author for simple fetch enhancements; recommended in README for users who don't need Got's full feature set
• sindresorhus/type-fest — Dependency used throughout Got for TypeScript utility types; learning Got's types means understanding type-fest

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for diagnostics-channel.ts

The source/core/diagnostics-channel.ts file provides diagnostic channel integration for monitoring HTTP requests, but there's no dedicated test file visible in the repository structure. This is a critical feature for production monitoring and debugging. Adding tests would ensure reliability of diagnostics events, proper error handling, and channel lifecycle management. This is especially important given Got's focus on being 'powerful' and production-ready.

• [ ] Create test/core/diagnostics-channel.test.ts with tests for channel creation and event emission
• [ ] Test all diagnostic channel event types (request start, response, error, retry)
• [ ] Test integration with Node.js diagnostics_channel API and ensure proper resource cleanup
• [ ] Verify compatibility with APM tools that consume these channels (DataDog, New Relic, etc.)
• [ ] Add tests for edge cases like channel errors and listener attachment/detachment

Add tests for parse-link-header.ts RFC 8288 compliance edge cases

The source/core/parse-link-header.ts file handles pagination link parsing which is critical for the documented pagination feature (documentation/4-pagination.md). While basic parsing is likely tested, RFC 8288 has many edge cases around malformed headers, special characters, and parameter ordering that could cause bugs in production. Tests should validate compliance with the spec for various real-world API responses.

• [ ] Create test/core/parse-link-header.test.ts with RFC 8288 edge case tests
• [ ] Test malformed link headers, escaped characters, and missing relation types
• [ ] Test multiple links with same relation type and parameter ordering variations
• [ ] Test pagination with real-world API responses (GitHub, GitLab pagination patterns)
• [ ] Add fuzz testing or property-based tests using fast-check for header parsing robustness

Add integration tests for WeakableMap utility in cache scenarios

The source/core/utils/weakable-map.ts is a foundational utility for Got's caching system (documentation/cache.md), but lacks dedicated integration tests showing its behavior in realistic caching scenarios. This utility manages weak references for DNS caching and request caching, making it critical for memory efficiency. Tests should verify weak reference collection doesn't interfere with active caches and that fallback to regular Map works correctly.

• [ ] Create test/core/utils/weakable-map.test.ts with weak reference behavior tests
• [ ] Test garbage collection of unreferenced cache entries and memory cleanup
• [ ] Test fallback behavior when WeakMap is unavailable or disabled
• [ ] Test concurrent access patterns and race conditions in cache lookups
• [ ] Add integration tests showing WeakableMap usage with cacheable-lookup and cacheable-request dependencies

• Add missing examples in documentation/examples/ for advanced scenarios like custom agent pools or certificate pinning (suggested by https in documentation/5-https.md but no runnable example present)
• Expand source/as-promise/types.ts with stricter overloads for responseType: 'json' to auto-infer response body type without explicit <T> generics (TypeScript DX improvement)
• Add integration test coverage for edge cases in source/core HTTP/2 request handling via http2-wrapper, indicated by documentation/examples/h2c.js existing but no test file pairing visible

The 'got' HTTP library demonstrates solid security practices overall. The codebase is well-maintained, uses modern Node.js (>=22), and includes comprehensive test coverage. Key strengths include: no hardcoded secrets in visible files, no injection attack surfaces (library is HTTP abstraction, not user-facing UI), and active security policy. Minor concerns include: flexible dependency versioning that could benefit from stricter pinning, truncated .npmrc visibility, and lack of visible SBOM generation. The project's security posture is good for a production HTTP client library, with proper dependency management through npm audit and CI/CD testing. No critical vulnerabilities detected in the analyzed file structure.

• Medium · Node.js Version Requirement May Limit Security Updates — package.json - engines field. The package requires Node.js >=22, which excludes users on earlier LTS versions. While this ensures access to latest security patches, it may limit adoption and create pressure for users to skip security updates on older Node versions before upgrading. Fix: Consider supporting Node.js 20 LTS if feasible, or provide clear migration guidance for users on older versions. Ensure security advisories are published prominently.
• Low · Dependency Pinning Could Be Stricter — package.json - dependencies section. Several dependencies use caret (^) version specifiers, allowing minor and patch updates automatically. While this enables security patches, it could introduce unexpected breaking changes in transitive dependencies. Fix: Consider using more restrictive version pinning (e.g., ~) for critical dependencies, or implement automated dependency scanning with Dependabot. Current setup with 'npm ci' in CI/CD mitigates some risk.
• Low · No Integrity Check Configuration Visible — .npmrc. The .npmrc file is present but its contents are truncated in the provided context. If it lacks 'audit=true' or similar configurations, security audits may not be enforced during installation. Fix: Ensure .npmrc contains 'audit=true' and consider adding 'engine-strict=true' to enforce Node.js version requirements. Verify npm audit is run in CI/CD pipelines.
• Low · Test Files May Contain Sensitive Data Patterns — test/ directory, particularly test/fixtures/. Test fixtures and test files (test/fixtures, test/*.ts) may contain hardcoded test credentials, API keys, or sensitive URLs that could be exposed if repository is public or accidentally leaked. Fix: Audit test files for any hardcoded credentials, API keys, or sensitive data. Use environment variables or mock objects for sensitive test data. Implement pre-commit hooks to prevent secrets from being committed.
• Low · Missing Security Policy Visibility — .github/security.md. While .github/security.md exists, its contents are not provided. Security policy should be publicly visible and clearly documented. Fix: Ensure security.md contains clear vulnerability disclosure policy, supported versions, and security contact information. Make it easily discoverable in the repository.
• Low · No SBOM or Dependency Transparency — package.json - build scripts. No evidence of Software Bill of Materials (SBOM) generation or dependency transparency tooling in the build pipeline. Fix: Add SBOM generation to the build process using tools like 'npm sbom' (Node 19+) or 'cyclonedx-npm'. Consider publishing SBOMs with releases.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sindresorhus/got shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sindresorhus/got repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sindresorhus/got.

What it runs against: a local clone of sindresorhus/got — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sindresorhus/got | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sindresorhus/got. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sindresorhus/got.git
#   cd got
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sindresorhus/got and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sindresorhus/got(\\.git)?\\b" \\
  && ok "origin remote is sindresorhus/got" \\
  || miss "origin remote is not sindresorhus/got (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "source/index.ts" \\
  && ok "source/index.ts" \\
  || miss "missing critical file: source/index.ts"
test -f "source/core/index.ts" \\
  && ok "source/core/index.ts" \\
  || miss "missing critical file: source/core/index.ts"
test -f "source/as-promise/index.ts" \\
  && ok "source/as-promise/index.ts" \\
  || miss "missing critical file: source/as-promise/index.ts"
test -f "source/types.ts" \\
  && ok "source/types.ts" \\
  || miss "missing critical file: source/types.ts"
test -f "source/core/options.ts" \\
  && ok "source/core/options.ts" \\
  || miss "missing critical file: source/core/options.ts"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 34 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~4d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sindresorhus/got"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.