WAIT — OpenSSF Scorecard says this is unmaintained

• Last commit 2d ago
• 18 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 75% of recent commits
• ⚠ Scorecard: marked unmaintained (2/10)
• ⚠ Scorecard: default branch unprotected (0/10)

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

p-limit is a lightweight npm package that enforces concurrency limits on promise-returning and async functions, preventing resource exhaustion by queuing tasks and executing them in batches. It provides a drop-in function wrapper that limits how many promises run simultaneously, with utilities like .map() for batch processing, .activeCount and .pendingCount for monitoring, and .clearQueue() for cleanup. The core exports are a default pLimit(concurrency) factory and a named limitFunction(fn, options) export for decorating individual functions. Minimal flat structure: index.js contains the main implementation (~100 lines), index.d.ts provides TypeScript types, index.test-d.ts validates type definitions with tsd, and test.js contains the ava test suite. benchmark.js and scripts/benchmarker.js measure performance. No monorepo or internal packages; everything ships from the repo root as a single npm module.

Backend and frontend developers who need to throttle concurrent API calls, database queries, or file operations without external rate-limiting services. Common users include: Node.js server authors managing connection pools, browser app developers limiting fetch requests, and CLI tool creators processing large batches of items (e.g., bulk file uploads, web scraping, or database bulk operations) where uncontrolled concurrency would cause memory or network issues.

Production-ready and actively maintained. The v7.3.0 release targets Node.js >=20, has a full test suite (test.js), TypeScript definitions (index.d.ts), CI/CD via GitHub Actions (main.yml), and is authored by Sindre Sorhus (prolific open-source maintainer). The codebase is minimal (~25KB JavaScript) with a single external dependency (yocto-queue), indicating stability and low surface area for bugs.

Very low risk. Only one production dependency (yocto-queue ^1.2.1), no breaking changes visible in v7.3.0, and the author is a trusted maintainer with strong reputation. The main risk is single-point-of-failure if yocto-queue has issues, but that package is also well-maintained. No evidence of stale issues or PRs; the code is simple enough that maintenance burden is minimal.

The project is in maintenance mode—v7.3.0 is current, and the focus is on stability and minor improvements. The CI pipeline (workflows/main.yml) runs xo linting, ava tests, and tsd type checks on each commit. No active feature development is visible, but the repo accepts PRs for bugfixes and performance improvements (as evidenced by benchmark.js presence).

git clone https://github.com/sindresorhus/p-limit.git
cd p-limit
npm install
npm test

Daily commands: This is a library, not a runnable app. To verify it works: npm test runs xo (linting), ava (unit tests), and tsd (type checking). To benchmark: npm run benchmark (runs benchmark.js). There is no dev server.

• index.js — Core implementation of the concurrency limiter; the entire library logic resides here and all users depend on its correctness.
• index.d.ts — TypeScript type definitions that define the public API contract; essential for type-safe usage across the ecosystem.
• package.json — Declares the library's contract: Node.js >=20 requirement, ES modules format, and exported entry points that all consumers rely on.
• test.js — Comprehensive test suite validating core concurrency behavior, edge cases, and queue clearing logic; the safety net for refactoring.
• readme.md — Primary documentation; developers must understand the API, concurrency semantics, and usage patterns before contributing or using the library.

• limit() function wrapper (JavaScript Promise, closure scope) — Entry point that accepts a function and arguments, enqueues it, manages promise lifecycle, and returns a promise to the caller
  • Failure mode: If queue management is broken, tasks may run beyond concurrency limit or silently deadlock
• Active promise pool (WeakMap or Set for active promise tracking, Promise.prototype.finally()) — Tracks currently executing promises; when one completes, triggers dequeuing of the next pending task
  • Failure mode: If pool tracking fails, concurrency limit may be exceeded or tasks may never execute
• Pending task queue (Array or linked-list-like structure) — FIFO queue of functions and their arguments awaiting an available concurrency slot
  • Failure mode: If queue is lost or corrupted, pending tasks are orphaned and never run
• clearQueue() handler (Promise.reject, Error subclass or AbortError) — Drains pending tasks and optionally rejects them with AbortError; useful for cleanup or cancellation
  • Failure mode: If not properly awaited, callers may see dangling promises; if rejectOnClear is false, pending work silently discarded

• User Code → limit() wrapper — Passes async function and arguments to be rate-limited
• limit() wrapper → Pending Queue — Enqueues function if concurrency limit reached; otherwise passes directly to Active Pool
• Active Pool → User Promise Function — Invokes the user's async function with provided arguments
• User Promise Function → Active Pool — Returns Promise; pool awaits its settlement (resolve/reject)
• Active Pool → Pending Queue — Checks queue for next task when a promise settles and a slot opens
• Pending Queue → Active Pool — Dequeues next task and moves it to Active Pool
• Active Pool → User Code — Resolves or rejects the promise returned to the caller with the function's result

Add a new concurrency limiter option

1. Add the new option parameter to the options object type in index.d.ts (index.d.ts)
2. Implement the option logic in the limit function and queue management in index.js (index.js)
3. Add test cases covering the new option in test.js (test.js)
4. Document the new option in the API section of readme.md (readme.md)

Add a new usage recipe

1. Create a named section in recipes.md with problem statement and solution code (recipes.md)
2. Reference the recipe in the appropriate section of readme.md (readme.md)

Improve concurrency algorithm performance

1. Profile current behavior using benchmark.js (benchmark.js)
2. Modify the queue and execution logic in index.js (index.js)
3. Run test.js to verify no regressions in behavior (test.js)
4. Update benchmark.js if measuring a new metric, then commit results (benchmark.js)

• ES modules (import/export) — Modern JavaScript standard; enables tree-shaking and is the platform default for Node.js >=14; aligns with Sindre's ecosystem
• Promise-based API — Native JavaScript async primitive; no external dependencies; seamless integration with async/await and Promise.all patterns
• TypeScript type definitions (.d.ts) — Provides IDE autocomplete and type safety for users in both TypeScript and modern JavaScript projects without a build step
• Node.js >=20 — Latest LTS releases; supports all modern JavaScript features; reduces legacy burden

• No external dependencies (zero-dependency library)

  • Why: Minimizes supply-chain risk, reduces bundle size for consumers, simplifies maintenance
  • Consequence: All queue and concurrency logic must be implemented from scratch; less battle-tested infrastructure but full control and transparency

• Simple queue with FIFO semantics for pending tasks

  • Why: Predictable, easy to reason about, matches user expectations for fairness
  • Consequence: No priority queue support; all enqueued functions wait equally regardless of urgency

• AbortError rejection on clearQueue() (opt-in)

  • Why: Allows callers to handle pending task cancellation explicitly without leaving dangling promises
  • Consequence: Requires explicit error handling when using clearQueue(); can mask bugs if not properly caught

• Synchronous-only API (no eventEmitter or callbacks)

  • Why: Simpler mental model; promises already provide completion notification; fewer API surface area
  • Consequence: No granular event hooks for queue state changes; monitoring requires external wrappers

• Does not provide real-time monitoring/metrics of queue state (no event emitter or observer pattern)
• Does not prioritize or reorder queued tasks (strictly FIFO)
• Does not support cancellation of in-flight promises (only prevents new queued tasks via clearQueue)
• Does not persist queue state across process restarts
• Not a full-featured job queue library (e.g., Bull, BullMQ, RabbitMQ style); focused narrowly on in-memory concurrency control

• Implicit global state in limit function (Low) — index.js: The limit function maintains internal queue and active set as closure variables; while intentional for encapsulation, it means each call to pLimit() creates a separate limiter instance, which can be confused if developers expect a shared global limiter
• No timeout or max retry logic (Medium) — index.js: If a user's promise function hangs indefinitely, the slot is never freed and subsequent queued tasks starve; no built-in watchdog or timeout mechanism
• AbortError not from standard AbortController (Low) — index.js: The rejectOnClear option creates an AbortError but does not integrate with standard AbortController/AbortSignal, making it incompatible with broader cancellation patterns

• index.js: active promise .finally() handler (undefined) — Every settled promise triggers a synchronous finally callback that dequeues and spawns the next task; under very high concurrency or rapid queue ch

None obvious. The main gotcha documented in the README is: 'Avoid calling the same limit function inside a function that is already limited by it. This can create a deadlock.' This is a design limitation, not a bug. There are no required environment variables, services, or config files. Node.js >=20 is hard requirement (no Node 18 support).

• Token bucket rate limiting — p-limit implements a soft token bucket: tasks consume a 'slot' when they start (activeCount++), and release it when done; the bucket size is the concurrency limit. Understanding this model clarifies how limits are enforced.
• FIFO queue (First-In-First-Out) — p-limit delegates to yocto-queue for FIFO task scheduling; pending tasks run in the order submitted, which is crucial for predictable and fair concurrency control.
• Promise-based async coordination — The entire library uses Promise state (resolve/reject/pending) to coordinate task execution without callbacks; learning how index.js chains promises to manage the queue is key to understanding the implementation.
• Deferred / Promise executor pattern — p-limit wraps each task in a deferred promise (created via the executor function); when a slot opens, the deferred is resolved, allowing the task to run. This decouples task submission from execution.
• Backpressure and resource pooling — p-limit prevents 'backpressure' by refusing to overload the system with concurrent tasks; this is essential in I/O-bound scenarios (databases, APIs) where uncontrolled concurrency exhausts connection pools.
• AbortError and graceful shutdown — When rejectOnClear is true, pending tasks are rejected with AbortError; understanding this pattern is critical for robust cleanup and avoiding hanging promises in long-lived services.

• sindresorhus/p-queue — More feature-rich queue with priority, pause/resume, and timeout support; p-limit is the minimal alternative for simple concurrency control.
• sindresorhus/p-map — Companion utility for mapping over iterables with concurrency limits; p-limit is the lower-level primitive it could be built on top of.
• pouchdb/pouchdb-promise — Uses p-limit internally for managing concurrent database operations, showing real-world usage pattern.
• node-fetch/node-fetch — Common use case: developers pair p-limit with node-fetch to throttle HTTP requests and avoid connection pool exhaustion.
• sindresorhus/awesome-npm-scripts — Sindre's curated list often recommends p-limit for task runners that need concurrency control without heavy orchestration.

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 error handling tests in test.js

The test.js file likely lacks comprehensive coverage for edge cases around error handling, especially for the rejectOnClear feature mentioned in the README. Currently, there are no visible tests for scenarios like: what happens when clearQueue() is called with pending promises, how AbortError is thrown, and behavior with mixed successful/failed promises. This is critical for a concurrency control library.

• [ ] Add test cases in test.js for clearQueue() with rejectOnClear: true/false
• [ ] Test AbortError rejection behavior when clearQueue() interrupts pending tasks
• [ ] Add tests for Promise.all() with clearQueue() to verify no hanging promises
• [ ] Verify error messages and stack traces are preserved correctly

Add browser compatibility tests in .github/workflows/main.yml

The README states 'Works in Node.js and browsers' but the only visible test script is xo && ava && tsd, which are Node-focused. There's no CI workflow for browser environments (jsdom, playwright, or similar). This is a critical gap for a library that claims browser support.

• [ ] Create new GitHub Actions workflow in .github/workflows/ for browser testing
• [ ] Add browser test environment using jsdom or similar in devDependencies
• [ ] Create browser-specific test suite or modify test.js with browser detection
• [ ] Test TypeScript types compilation for browser usage (index.d.ts)

Expand recipes.md with practical patterns and add tests for them

The recipes.md file exists but is likely minimal. The library has advanced features like rejectOnClear, options objects, and queue management that deserve documented patterns. Each recipe should have corresponding tests to ensure examples work correctly.

• [ ] Document 3+ real-world patterns in recipes.md (e.g., retry logic, timeout handling, progress tracking)
• [ ] Add specific test cases in test.js that verify each recipe pattern works as documented
• [ ] Include example for using p-limit with AbortController for cancellation
• [ ] Document memory/performance implications when using very high concurrency limits

• Add an optional .reset() method (distinct from .clearQueue()) that clears the queue without rejecting pending promises and optionally resets concurrency to the original value. This would require modifying index.js to track the initial concurrency and add the method, plus tests in test.js.
• Expand the recipes.md file with concrete examples for common patterns: (1) retrying failed tasks with exponential backoff, (2) combining p-limit with AbortController for cancellation, (3) using p-limit with promise pools for streaming data. This requires no code changes, just documentation.
• Add a .drainQueue() method that returns a promise resolving when all pending and active tasks complete, useful for graceful shutdown. Implementation would add a deferred promise in index.js that resolves when activeCount and pendingCount both hit zero.

This is a well-maintained, security-conscious utility library. The codebase has minimal attack surface as it's a pure JavaScript promise-limiting utility with no I/O operations, database interactions, or file system access. No hardcoded secrets, injection vulnerabilities, or dangerous patterns were identified. The single dependency (yocto-queue) is a legitimate, minimal utility. Development dependencies are appropriate and well-known packages. The project follows security best practices with proper licensing, maintains security documentation (.github/security.md), and uses standard linting/testing tools. No critical or high-severity vulnerabilities detected.

• Low · Dependency Version Constraints — package.json - dependencies. The dependency 'yocto-queue' uses a caret range (^1.2.1) which allows minor and patch version updates. While this is standard practice, it means automatic updates could introduce unexpected changes. However, as a small utility library with no known security issues, this is a minimal concern. Fix: Continue monitoring yocto-queue for security advisories. Consider using npm audit regularly to check for vulnerabilities.
• Low · Node.js Engine Requirement — package.json - engines. The package requires Node.js >=20, which is good practice as it ensures users are on relatively recent versions. However, this may exclude some legacy environments that haven't updated. Fix: No immediate action needed. The version requirement is reasonable and excludes EOL Node versions.

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/p-limit 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/p-limit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sindresorhus/p-limit.

What it runs against: a local clone of sindresorhus/p-limit — 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/p-limit | 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 ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sindresorhus/p-limit. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sindresorhus/p-limit.git
#   cd p-limit
#
# 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/p-limit and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sindresorhus/p-limit(\\.git)?\\b" \\
  && ok "origin remote is sindresorhus/p-limit" \\
  || miss "origin remote is not sindresorhus/p-limit (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 "index.js" \\
  && ok "index.js" \\
  || miss "missing critical file: index.js"
test -f "index.d.ts" \\
  && ok "index.d.ts" \\
  || miss "missing critical file: index.d.ts"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "test.js" \\
  && ok "test.js" \\
  || miss "missing critical file: test.js"
test -f "readme.md" \\
  && ok "readme.md" \\
  || miss "missing critical file: readme.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
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/p-limit"
  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.