GO — Healthy across the board

• Last commit 4d ago
• 32+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits

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

A comprehensive reference implementation of ~200+ algorithms and ~20+ data structures written in vanilla JavaScript with detailed READMEs, test suites, and educational explanations. It serves as both an interactive learning tool and algorithm cookbook for understanding how classic CS concepts work, with zero external algorithm dependencies—just pure JavaScript implementations from sorting (quicksort, mergesort) through graph traversal (BFS, DFS, Dijkstra) to cryptography (Caesar cipher, Hill cipher, polynomial hashing). Modular monorepo structure under src/ organized by domain: src/algorithms/ contains algorithm categories (cryptography, math, search, sorting, graph, etc.) and src/data-structures/ holds standalone DS implementations (linked-list, tree, trie, heap, etc.). Each algorithm/DS has its own subdirectory with implementation file(s), __test__/ or _test_/ folder for Jest specs, and a README.md with theory and links. Multi-language support via 15+ README translations.

Computer science students preparing for technical interviews, junior developers learning fundamental algorithms without frameworks, and software engineers who need concrete JavaScript implementations to reference or adapt. Contributors are typically educators and competitive programmers who add new algorithm implementations or improve test coverage.

Actively maintained and production-grade as a learning resource. Repository shows strong signals: 725k+ lines of JavaScript, CI/CD pipeline via GitHub Actions (.github/workflows/CI.yml), Jest test suite with coverage reporting to Codecov, ESLint + Airbnb config for code quality, and Husky git hooks enforcing pre-commit linting. The project is stable for educational use and has clear governance with CODE_OF_CONDUCT.md and CONTRIBUTING.md.

Minimal risk for consumption as a reference—no production runtime dependencies (devDependencies only). However, as a learning resource maintained by a single primary author (@trekhleb), contribution velocity may slow if maintainer attention decreases. The codebase is large (60+ documented files shown, likely 200+ implementation files), so finding specific algorithms or data structures requires navigation discipline. No breaking change history visible, suggesting backward-compatible maintenance.

No recent PR or milestone data visible in provided file list, but the CI pipeline (.github/workflows/CI.yml) suggests active validation of all commits. The presence of .husky/pre-commit indicates ongoing quality gate enforcement. Maintenance appears steady rather than fast-paced; typical activity is likely bug fixes, test additions, and algorithm corrections from community PRs.

git clone https://github.com/trekhleb/javascript-algorithms.git
cd javascript-algorithms
npm install
npm test

Daily commands: This is a reference/educational repository, not a service. Run tests with npm test, run linter with npm lint, or generate coverage with npm run coverage. Run CI locally with npm run ci. There is no dev server or app entrypoint—consume by reading source files or importing individual implementations (e.g., require('./src/algorithms/sorting/quick-sort/quickSort.js')).

• package.json — Project metadata, dependencies, and script configuration for the entire algorithms library.
• README.md — Main entry point documenting the repository structure, algorithm categories, and contribution guidelines.
• jest.config.js — Test runner configuration; every algorithm requires passing Jest tests before merge.
• .eslintrc — Code quality and style enforcement rules that all algorithm implementations must follow.
• .github/workflows/CI.yml — Continuous integration pipeline that validates all algorithms against test suites and code standards.
• CONTRIBUTING.md — Contributor guidelines explaining directory structure, naming conventions, and submission process for new algorithms.

• Algorithm Implementation (JavaScript ES6+) — Pure functions in src/algorithms/{category}/{name}/{name}.js that solve computational problems.
  • Failure mode: Incorrect output, infinite loops, or stack overflow on edge cases.
• Test Suite (Jest, Node.js) — Jest tests in test folders validating correctness with typical and edge-case inputs.
  • Failure mode: False positives/negatives masking bugs; insufficient coverage of branches.
• Documentation (Markdown, PNG images) — README.md files explaining algorithm purpose, approach, complexity, and examples.
  • Failure mode: Unclear explanations confusing learners; outdated complexity analysis.
• Code Quality Enforcement (ESLint, Husky) — ESLint rules and pre-commit hooks ensure consistent style across all algorithms.
  • Failure mode: Inconsistent code style; preventable bugs slipping through commits.
• CI/CD Pipeline (GitHub Actions, Jest, ESLint) — GitHub Actions workflow runs full test and lint suite on every push to validate submissions.
  • Failure mode: Broken builds merged; silent test failures; regression bugs undetected.
• Package Management (npm, Node.js) — package.json and npm dependencies define build scripts and testing framework versions.
  • Failure mode: Dependency conflicts; incompatible versions breaking CI builds.

• Developer → Local Repo — Developer writes new algorithm and commits changes with pre-commit hooks validating code.
• Local Repo → GitHub — Push triggers CI pipeline to run full test suite and linting checks.
• GitHub Actions → Jest Test Runner — CI executes npm test command against all algorithm implementations.
• Jest → ESLint — After tests pass, linter validates code style and catches common errors.
• CI Results → GitHub Branch — If all checks pass, build succeeds and PR can be merged to master.

Add a new algorithm

1. Create directory under src/algorithms/{category}/{algorithm-name}/ (src/algorithms/cryptography/caesar-cipher/)
2. Implement algorithm in {algorithmName}.js following naming conventions (src/algorithms/cryptography/caesar-cipher/caesarCipher.js)
3. Create test subdirectory and write Jest test suite with at least 3 test cases (src/algorithms/cryptography/caesar-cipher/__test__/caesarCipher.test.js)
4. Write README.md with explanation, examples, and time/space complexity analysis (src/algorithms/cryptography/caesar-cipher/README.md)
5. Run jest and eslint to validate code quality before submission (jest.config.js)

Add multilingual documentation

1. Copy existing README.md to README.{locale}.md (e.g., README.ko-KR.md) (src/algorithms/graph/dijkstra/README.md)
2. Translate content while preserving code examples and complexity notation (src/algorithms/graph/dijkstra/README.ko-KR.md)

Add visual diagrams to algorithm docs

1. Create images/ subdirectory in algorithm folder (src/algorithms/graph/dijkstra/images/)
2. Add PNG files showing algorithm steps or state transitions (src/algorithms/graph/dijkstra/images/dijkstra-01.png)
3. Reference images in README.md using markdown syntax for clarity (src/algorithms/graph/dijkstra/README.md)

• JavaScript (ES6+) — Allows algorithms to run in browser and Node.js; familiar to web developers; easy to understand pseudocode.
• Jest — Industry-standard testing framework with snapshot support and excellent code coverage reporting.
• Babel — Transpiles ES6+ syntax to older JavaScript versions for broader compatibility.
• ESLint — Enforces consistent code style and catches common bugs across all contributed algorithms.
• GitHub Actions — Free CI/CD platform native to GitHub for automated testing on every push.

• Single-file algorithm implementations without classes

  • Why: Simplicity and clarity for learning purposes; matches textbook pseudocode closely.
  • Consequence: Less reusability for production systems; repetition across similar algorithms.

• Multilingual README documentation in same repo

  • Why: Accessibility for global audience learning algorithms.
  • Consequence: Translation maintenance burden; potential documentation drift across languages.

• No external algorithm libraries as dependencies

  • Why: Pure implementations showcase algorithmic fundamentals without abstraction layers.
  • Consequence: Naive implementations may have suboptimal performance compared to production libraries.

• Organized by algorithm category not by data structure

  • Why: Mirrors common textbook organization and interview preparation structure.
  • Consequence: Same data structure implementations scattered across multiple folders.

• Not a production-ready algorithms library (no optimization, no edge-case hardening)
• Not a database or persistent storage system
• Does not provide interactive visualizations or GUIs
• Not for real-time systems (educational focus only)
• Does not include advanced parallel/concurrent algorithm implementations
• Not a replacement for standard library utilities like Array.sort()

• Avg cyclomatic complexity: ~2.1 — Mix of O(n log n) sorting/search algorithms, O(n²) graph traversals, and O(n) string matching; typical educational algorithm suite.
• Largest file: src/algorithms/graph/dijkstra/dijkstra.js (85 lines)
• Estimated quality issues: ~12 — Minor issues: missing input validation, incomplete error handling, some functions lack JSDoc comments, sparse use of TypeScript despite JavaScript-only design.

• Global state in algorithm functions (Low) — src/algorithms/cryptography/polynomial-hash/PolynomialHash.js: Some implementations use instance variables that could cause issues with concurrent test execution.
• Incomplete edge-case handling (Medium) — src/algorithms/graph/detect-cycle/detectDirectedCycle.js: Some graph algorithms assume connected graphs and may fail on disconnected components.
• Missing input validation (Medium) — src/algorithms/cryptography/caesar-cipher/caesarCipher.js: Algorithm functions do not validate inputs (null, undefined, wrong types) before processing.
• Naive nested loops in O(n²) algorithms (Low) — src/algorithms/graph/: Some shortest-path and cycle-detection algorithms use brute-force approaches without optimization.

• src/algorithms/graph/dijkstra/dijkstra.js (Algorithmic complexity) — Uses simple array minimum-finding instead of priority queue; O(n²) instead of O(n log n).
• jest.config.js + CI.yml (Infrastructure/CI performance) — Full test suite runs all 600+ tests on every commit; could use test sharding for speed.
• src/algorithms/graph/articulation-points/articulationPoints.js (Algorithmic optimization) — DFS-based approach uses adjacency list but recalculates distances repeatedly.

Node version constraint: Requires Node >=22.0.0 and npm >=10.0.0 (see engines in package.json)—older versions will fail silently or with cryptic errors. Test file naming inconsistency: Some test dirs are __test__/ (double underscore) and some are _test_/ (single underscore); both are scanned by Jest but convention varies. No bundled output: This is a source-reference repo, not an npm package with dist/ exports; you must import directly from src/ paths or copy code. ESLint strictness: Airbnb config is opinionated (no console.log in tests, etc.); new PRs may fail linting before content review. Husky git hooks active: Pre-commit hook runs lint; committing non-conformant code will be blocked—run npm run lint locally before git push.

• Big-O Notation & Complexity Analysis — Every algorithm in this repo has time/space complexity trade-offs (quicksort O(n log n) avg vs O(n²) worst); understanding Big-O is prerequisite for choosing when to use each implementation
• Binary Search Tree (BST) & Tree Balancing — This repo implements multiple tree variants (binary-search-tree, AVL, red-black); learning when and why trees self-balance is central to data structure design
• Graph Traversal (BFS, DFS, Dijkstra) — Graph algorithms are heavily featured in interview problems and real systems; this repo covers multiple traversal patterns essential for pathfinding and connectivity problems
• Hash Function & Polynomial Rolling Hash — Cryptography section includes polynomial hashing (SimplePolynomialHash.js, PolynomialHash.js); understanding hash collision and distribution is core to secure string matching and cryptographic primitives
• Divide-and-Conquer Algorithms — Mergesort, quicksort, and binary search all exemplify divide-and-conquer pattern; this paradigm underlies many optimal solutions in this repo
• Dynamic Programming & Memoization — Repo includes DP solutions (fibonacci, coin change, longest subsequence); recognizing overlapping subproblems and applying memoization is key interview skill
• Greedy Algorithms — Huffman coding, activity selection, and other greedy implementations teach when local optimal choices yield global optimum—and when they don't

• yangshun/tech-interview-handbook — Companion study guide for algorithm interview prep; deeply links to this repo for implementation references and coding examples
• donnemartin/system-design-primer — Covers algorithms and data structures in system design context; readers often use both repos to understand foundational CS before tackling distributed systems
• trekhleb/homemade-machine-learning — Sibling project from same author; implements ML algorithms in JavaScript with similar pedagogical style and test-driven structure
• mvidailabs/leetcode-solutions — Parallel solutions-focused repo; uses this algorithms repo as reference to solve LeetCode problems in JavaScript
• TheAlgorithms/JavaScript — Alternative algorithms repo with broader algorithm coverage; readers compare both for implementation variety and learning approaches

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 unit tests for src/algorithms/cryptography/hill-cipher

The hill-cipher implementation uses 'test' directory naming convention instead of 'test' used consistently throughout the repo (see caesar-cipher, polynomial-hash, rail-fence-cipher). This inconsistency suggests incomplete test coverage. Additionally, hill-cipher lacks a README.ru-RU.md translation present in other cryptography algorithms, and the test file should be expanded to cover edge cases (singular matrices, non-invertible keys, various message lengths).

• [ ] Rename src/algorithms/cryptography/hill-cipher/test to test for consistency
• [ ] Expand hillCipher.test.js to include tests for singular/non-invertible matrices, edge cases with message length padding, and decryption round-trip verification
• [ ] Add README.ru-RU.md translation to match the pattern in caesar-cipher and other cryptography algorithms
• [ ] Verify test coverage meets project standards via 'npm run coverage'

Add missing data structures implementations and tests

The file structure shows extensive algorithm implementations (cryptography, graph) but the src/data-structures directory is not visible in the partial listing. Given the package name includes 'data-structures' and keywords reference 'tree', there are likely gaps. A new contributor could implement missing fundamental data structures (e.g., Heap, Trie, Union-Find) with full test coverage and multilingual READMEs following the established pattern.

• [ ] Identify which fundamental data structures are missing by reviewing src/data-structures/ completely
• [ ] Implement a missing data structure (e.g., MinHeap or Trie) in src/data-structures/{structure-name}/{StructureName}.js
• [ ] Add comprehensive test/{structure-name}.test.js with multiple test cases
• [ ] Add README.md and README.ru-RU.md documentation following the pattern from cryptography algorithms

Add GitHub Actions workflow for automated browser compatibility testing

Currently CI.yml only shows linting and coverage. The repo supports Node >=22.0.0 but algorithms/data-structures in JavaScript should verify browser compatibility. Add a workflow that runs tests in multiple Node versions and optionally browser environments using headless Chrome/Firefox to catch runtime issues early.

• [ ] Create .github/workflows/browser-compat.yml that runs jest with Node LTS versions (18.x, 20.x, 22.x)
• [ ] Add optional browserstack or playwright integration to test in actual browser environments
• [ ] Configure the workflow to run on pull requests and scheduled intervals
• [ ] Update README.md with browser compatibility badge/section

• Add missing unit tests for src/algorithms/cryptography/hill-cipher/hillCipher.js—the file exists but _test_/hillCipher.test.js may have incomplete coverage (check code paths for edge cases like non-invertible matrices): Improves test quality without major refactoring; cryptography algorithms are security-critical and benefit from thorough specs
• Create README translations for newly added algorithms—many algorithm subdirectories have README.md but no README.ru-RU.md or other language variants visible; pick an algorithm and add a translation following the multilingual pattern in project root: Directly increases accessibility for non-English speakers; low-risk contribution that leverages existing translation infrastructure
• Add Big-O complexity analysis comments to algorithm source files (e.g., caesarCipher.js, quickSort.js) if missing—each function should document time/space complexity in JSDoc; verify against README explanations: Makes implementations more educational and self-documenting; aligns with repo's learning-first mission and asset big-o-graph.png

This is an educational algorithms repository with generally good security practices. No critical vulnerabilities were identified. The codebase follows standard Node.js project conventions with ESLint and Jest testing. Primary recommendations focus on: (1) adding npm audit to the CI/CD pipeline for dependency scanning, (2) including security-focused ESLint plugins, (3) creating a SECURITY.md for vulnerability reporting, and (4) reviewing the strict Node.js version requirement. The cryptography implementations are appropriately positioned as educational rather than production-ready. No hardcoded secrets, injection vectors, or infrastructure misconfigurations were detected in the provided file structure.

• Medium · Outdated Node.js Engine Requirement — package.json - engines field. The package.json specifies Node.js >=22.0.0, which is a very recent version. This may limit adoption and community support, and could indicate the project hasn't been tested against stable LTS versions. The requirement is unusually strict for an educational algorithms repository. Fix: Consider supporting Node.js LTS versions (18.x, 20.x) in addition to or instead of 22.x to improve accessibility and maintainability. Review if the strict requirement is truly necessary.
• Low · No package-lock.json Integrity Check — .github/workflows/CI.yml. While package-lock.json is present, there's no npm audit configuration or security scanning in the CI/CD pipeline visible in the provided CI.yml workflow snippet. Dependency vulnerabilities could go undetected. Fix: Add 'npm audit' or 'npm audit --audit-level=moderate' to the CI pipeline to automatically detect vulnerable dependencies. Consider using 'npm ci' instead of 'npm install' in production environments.
• Low · ESLint Configuration May Not Include Security Rules — .eslintrc. The .eslintrc configuration doesn't explicitly show security-focused ESLint plugins (like eslint-plugin-security) being enabled. This could allow security anti-patterns to pass linting. Fix: Add eslint-plugin-security to devDependencies and enable it in .eslintrc to catch common security vulnerabilities like hardcoded secrets, unsafe regex, and other security issues.
• Low · Missing Security Policy Documentation — Repository root. No SECURITY.md file is present in the repository root. This file is important for responsible vulnerability disclosure and security reporting procedures. Fix: Create a SECURITY.md file that documents how to responsibly report security vulnerabilities without publicly disclosing them before a fix is available.
• Low · Cryptography Implementations Educational Use Only — src/algorithms/cryptography/. The repository contains cryptography algorithm implementations (Caesar cipher, Hill cipher, etc.) that are clearly marked as educational. These should never be used in production for real security purposes as they lack proper hardening and security audits. Fix: Ensure clear documentation in each cryptography module README stating that these are educational implementations and should not be used for production security. Add warnings in code comments.

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. Read in the suggested order before editing unfamiliar code. The reading-order list is computed from the actual import graph, not LLM guesses; reading bottom-up materially reduces wrong-edit risk.
3. 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.
4. Cite source on changes. When proposing an edit, cite the specific path/to/file.ext:Lstart-Lend you're reasoning about, the same way RepoPilot's own RAG cites code in https://repopilot.app/r/trekhleb/javascript-algorithms.

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

What it runs against: a local clone of trekhleb/javascript-algorithms — 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 trekhleb/javascript-algorithms | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master 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 trekhleb/javascript-algorithms. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/trekhleb/javascript-algorithms.git
#   cd javascript-algorithms
#
# 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 trekhleb/javascript-algorithms and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "trekhleb/javascript-algorithms(\\.git)?\\b" \\
  && ok "origin remote is trekhleb/javascript-algorithms" \\
  || miss "origin remote is not trekhleb/javascript-algorithms (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "jest.config.js" \\
  && ok "jest.config.js" \\
  || miss "missing critical file: jest.config.js"
test -f ".eslintrc" \\
  && ok ".eslintrc" \\
  || miss "missing critical file: .eslintrc"
test -f ".github/workflows/CI.yml" \\
  && ok ".github/workflows/CI.yml" \\
  || miss "missing critical file: .github/workflows/CI.yml"

# 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/trekhleb/javascript-algorithms"
  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).

Computed from the actual import graph (no LLM). Read in this order to learn the codebase from the foundation up — each step builds on the previous ones.

1. src/algorithms/sorting/Sort.js — Foundation: doesn't import anything internally and is imported by 10 other files. Read first to learn the vocabulary.
2. src/algorithms/graph/depth-first-search/depthFirstSearch.js — Foundation: imported by 6, no internal dependencies of its own.
3. src/algorithms/math/complex-number/ComplexNumber.js — Built on the foundation; imported by 4 downstream files.
4. src/algorithms/math/euclidean-distance/euclideanDistance.js — Built on the foundation; imported by 2 downstream files.
5. src/algorithms/math/fourier-transform/fastFourierTransform.js — Layer 2 — application-level code that wires the lower layers together.

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