cspell

cspell is a command-line tool and library for spell checking source code. Instead of matching raw text against a dictionary, it parses code into words first, splitting camelCase, snake_case, and compound identifiers apart, so it can catch typos in variable names, comments, and strings without flooding you with false positives on ordinary code constructs.

It ships with no external OS-level dependencies (no Hunspell or aspell) and bundles a large family of built-in dictionaries for languages, frameworks, and file formats — JavaScript, TypeScript, Python, PHP, C#, C++, LaTeX, Go, HTML, CSS, and more. It’s built to run as a linter in CI pipelines and pre-commit hooks, or interactively via the companion Code Spell Checker extension for Visual Studio Code.

What You Get

• A cspell CLI with lint, trace, check, suggest, init, link, and dictionaries subcommands, driven by Commander
• Camel-case, snake_case, and compound-word aware tokenization so identifiers are split into real words before checking
• Dozens of bundled, curated dictionaries for programming languages, frameworks, and common file formats
• Glob-based and gitignore-aware file selection so large repos can be checked selectively and quickly
• A worker-thread based checking pipeline for parallel processing of many files
• A --cache mode with content or metadata cache strategies to speed up repeat CI runs
• A programmatic API (lint, trace, checkText) for embedding spell checking in other tools

Common Use Cases

• Adding a spelling lint step to CI so typos in code, comments, and docs fail the build
• Running as a pre-commit hook to catch misspelled identifiers and strings before they’re committed
• Checking documentation and README files for spelling errors alongside source code
• Powering the Code Spell Checker VS Code extension for real-time in-editor spell checking
• Auditing changed files only via git diff --name-only | npx cspell --file-list stdin in pull requests

Under The Hood

Architecture cspell is a pnpm-workspace monorepo where the published cspell package (packages/cspell) is a thin CLI/API layer: app.mts wires Commander-based subcommands (lint, trace, check, suggest, init, link, dictionaries) which delegate to cspell-lib for settings merging, tokenization, and dictionary lookup. Supporting workspace packages — cspell-dictionary, cspell-glob, cspell-io, cspell-gitignore, cspell-config-lib — handle globbing, gitignore-aware traversal, config-file resolution, and file IO, while cspell-worker offloads per-file checking to worker threads for parallelism, coordinated through lint/processFiles.ts and lint/processFile.ts. Because every bundled dictionary is built around a shared trie format consumed through cspell-dictionary, that abstraction is the one piece the rest of the pipeline is most tightly coupled to.

Tech Stack The codebase is TypeScript throughout, targeting Node 22.18+, built with tsdown and tsc for dual ESM/CJS output. The CLI layer uses Commander for argument parsing and chalk/chalk-template for terminal output, with semver for engine checks and tinyglobby for globbing. A large family of @cspell/dict-* dictionary packages plus cspell-lib form the checking core. pnpm workspaces coordinate the monorepo, Vitest is the test runner, and ESLint plus Prettier enforce style, with GitHub Actions running test, lint, coverage, and CodeQL workflows.

Code Quality Vitest test files sit alongside source throughout src/ — commands, the application layer, lint pipeline, worker, and link modules all have companion .test.ts files, several backed by __snapshots__ directories for snapshot-based CLI output testing. The codebase is fully typed TypeScript with a dedicated cspell-types package for shared type definitions, internal dependencies are consumed as workspace:* packages rather than copy-pasted, and errors are surfaced through a dedicated ApplicationError/CheckFailed module rather than swallowed. CI runs ESLint, Prettier, CodeQL, and coverage collection on every push.

What Makes It Unique cspell doesn’t wrap an existing spell-checking engine like Hunspell or aspell — it implements its own tokenizer that understands programming-language identifier conventions (camelCase, snake_case, compound words) so it can spell-check variable and function names directly, paired with an extensive, curated set of per-language and per-framework dictionaries and a suggestion engine that proposes fixes using edit-distance and compound-word splitting. The novelty is less a single clever algorithm and more a comprehensive, actively maintained domain-specific dictionary and tokenization system that few alternatives match in coverage.