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
Download a pre-built binary (installable via gh-install).
Or use rust to install:
bash
cargo install typos-cli
Or use Homebrew to install:
bash
brew install typos-cli
Most commonly, you'll either want to see what typos are available with
bash
typos
Or have them fixed
bash
typos --write-changes
typos -w
If there is any ambiguity (multiple possible corrections), typos will just report it to the user and move on.
Sometimes, what looks like a typo is intentional, like with people's names, acronyms, or localized content.
To mark an identifier or word as valid, add it your _typos.toml by declaring itself as the valid spelling:
```toml
[default.extend-identifiers]
AttributeIDSupressMenu = "AttributeIDSupressMenu"
[default.extend-words]
teh = "teh" ```
For cases like localized content, you can disable spell checking of file contents while still checking the file name:
toml
[type.po]
extend-glob = ["*.po"]
check-file = false
(run typos --type-list to see configured file types)
If you need some more flexibility, you can completely exclude some files from consideration:
toml
[files]
extend-exclude = ["localized/*.po"]
typos 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 typos, anything else is an error.
Examples: ```bash
typos - --write-changes
typos dir/file --diff
typos dir/file --format json ```
You can see what the effective config looks like by running
bash
typos --dump-config -
You can then see how typos is processing your project with
bash
typos --files
typos --identifiers
typos --words
If you need to dig in more, you can enable debug logging with -v
tl;dr typos doesn't know about it yet
typos 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.