codetypo

Source code spell checker

Finds and corrects spelling mistakes among source code:

• Fast enough to run on monorepos
• Low false positives so you can run on PRs

Dual-licensed under MIT or Apache 2.0

Documentation

• Installation
• Getting Started
  • False Positives
  • Integrations
    • GitHub Action
    • pre-commit
    • Custom
  • Debugging
• Reference
• FAQ
• Comparison with other spell checkers
• Projects using codetypo
• Benchmarks
• Design
• Contribute
• CHANGELOG

Install

Download a pre-built binary (installable via gh-install).

Or use rust to install:

$ cargo install codetypo-cli

Or use Homebrew to install:

$ brew install codetypo-cli

Or use Conda to install:

$ conda install codetypo

Or use Pacman to install:

$ sudo pacman -S codetypo

Getting Started

Most commonly, you'll either want to see what codetypo are available with

$ codetypo

Or have them fixed

$ codetypo --write-changes
$ codetypo -w

If there is any ambiguity (multiple possible corrections), codetypo will just report it to the user and move on.

False Positives

Sometimes, what looks like a typo is intentional, like with people's names, acronyms, or localized content.

To mark a word or an identifier (grouping of words) as valid, add it your _codetypo.toml by declaring itself as the valid spelling:

[default]
extend-ignore-identifiers-re = [
    # *sigh* this just isn't worth the cost of fixing
    "AttributeID.*Supress.*",
]

[default.extend-identifiers]
# *sigh* this just isn't worth the cost of fixing
AttributeIDSupressMenu = "AttributeIDSupressMenu"

[default.extend-words]
# Don't correct the surname "Teh"
teh = "teh"

For more ways to ignore or extend the dictionary with examples, see the config reference.

For cases like localized content, you can disable spell checking of file contents while still checking the file name:

[type.po]
extend-glob = ["*.po"]
check-file = false

(run codetypo --type-list to see configured file types)

If you need some more flexibility, you can completely exclude some files from consideration:

[files]
extend-exclude = ["localized/*.po"]

Integrations

• GitHub Actions
• pre-commit
• 🐊Putout Processor
• Visual Studio Code
• codetypo-lsp (Language Server Protocol server)

Custom

codetypo provides several building blocks for custom native integrations

• - reads from stdin, --write-changes will be written to stdout
• --diff to provide a diff
• --format json to get jsonlines with exit code 0 on no errors, code 2 on codetypo, anything else is an error.

Examples:

$ # Read file from stdin, write corrected version to stdout
$ codetypo - --write-changes
$ # Creates a diff of what would change
$ codetypo dir/file --diff
$ # Fully programmatic control
$ codetypo dir/file --format json

Debugging

You can see what the effective config looks like by running

$ codetypo --dump-config -

You can then see how codetypo is processing your project with

$ codetypo --files
$ codetypo --identifiers
$ codetypo --words

If you need to dig in more, you can enable debug logging with -v

FAQ

Why was ... not corrected?

Does the file show up in codetypo --files? If not, check your config with codetypo --dump-config -. The [files] table controls how we walk files. If you are using files.extend-exclude, are you running into #593? If you are using files.ignore-vcs = true, is the file in your .gitignore but git tracks it anyways? Prefer allowing the file explicitly (see #909).

Does the identifier show up in codetypo --identifiers or the word show up in codetypo --words? If not, it might be subject to one of codetypo' heuristics for detecting non-words (like hashes) or unambiguous words (like words after a \ escape).

If it is showing up, likely codetypo doesn't know about it yet.

codetypo maintains a list of known typo corrections to keep the false positive count low so it can safely run unassisted.

This is in contrast to most spell checking UIs people use where there is a known list of valid words. In this case, the spell checker tries to guess your intent by finding the closest-looking word. It then has a gauge for when a word isn't close enough and assumes you know best. The user has the opportunity to verify these corrections and explicitly allow or reject them.

For more on the trade offs of these approaches, see Design.

• To correct it locally, see also our False Positives documentation.
• To contribute your correction, see Contribute