Top Related Projects
Catch insensitive, inconsiderate writing
:pencil: A markup-aware linter for prose built with speed and extensibility in mind.
A linter for prose.
Naive linter for English prose
The pluggable natural language linter for text and markdown.
Quick Overview
Typos is a source code spell checker designed to find and fix spelling mistakes in your code, comments, and documentation. It's fast, supports multiple programming languages, and can be integrated into various development workflows.
Pros
- Fast performance, capable of checking large codebases quickly
- Supports multiple programming languages and file formats
- Customizable with ignore lists and custom dictionaries
- Can be integrated into CI/CD pipelines for automated spell checking
Cons
- May produce false positives for technical terms or intentional misspellings
- Limited to spelling checks, doesn't catch grammatical errors
- Requires some setup and configuration for optimal results
- May not catch context-specific spelling errors
Getting Started
To use Typos, follow these steps:
-
Install Typos:
cargo install typos-cli
-
Run Typos on your project:
typos
-
To automatically fix typos:
typos --write-changes
-
Create a configuration file (
.typos.toml
) to customize behavior:[default] extend-ignore-identifiers-re = [ "^IGNORE_ME_", ] [default.extend-words] gonna = "gonna" [files] extend-exclude = ["*.json"]
For more advanced usage and configuration options, refer to the official documentation.
Competitor Comparisons
Catch insensitive, inconsiderate writing
Pros of alex
- Focuses on inclusive and respectful language, addressing gender bias, racial issues, and other sensitive topics
- Integrates well with various text editors and CI/CD pipelines
- Provides explanations and suggestions for flagged words or phrases
Cons of alex
- May produce more false positives due to its broad scope of language analysis
- Requires more configuration to adapt to specific writing styles or contexts
- Slower performance compared to typos, especially on large codebases
Code comparison
alex:
const alex = require('alex');
const report = alex('He\'s the chairman of the committee.');
console.log(report.messages);
typos:
use typos::Config;
let config = Config::default();
let corrections = typos::check_file("README.md", &config)?;
for correction in corrections {
println!("{}", correction);
}
Key differences
- alex focuses on inclusive language and writing style, while typos primarily targets spelling errors
- alex is written in JavaScript and is more suitable for web-based projects, whereas typos is written in Rust and offers better performance for large-scale projects
- typos has a simpler API and is easier to integrate into existing workflows, while alex provides more detailed feedback and explanations for its suggestions
Both tools serve different purposes and can be complementary in a comprehensive text-checking workflow, with alex ensuring inclusive language and typos catching spelling mistakes.
:pencil: A markup-aware linter for prose built with speed and extensibility in mind.
Pros of Vale
- More comprehensive linting capabilities, including style and prose checks
- Highly customizable with support for custom rules and styles
- Integrates with various text editors and CI/CD pipelines
Cons of Vale
- Steeper learning curve due to more complex configuration
- Slower performance compared to Typos, especially on large codebases
- Requires more setup and maintenance for custom rules
Code Comparison
Vale configuration example:
StylesPath = styles
MinAlertLevel = suggestion
[*.md]
BasedOnStyles = Vale, proselint
Typos configuration example:
[default]
extend-ignore-identifiers-re = [
"^[A-Z]{2,}$",
]
Both tools offer configuration options, but Vale's configuration is more extensive due to its broader scope of linting capabilities. Typos focuses primarily on spelling errors, resulting in a simpler configuration.
A linter for prose.
Pros of proselint
- Focuses on writing style and clarity, not just spelling
- Provides detailed explanations for its suggestions
- Supports multiple languages and file formats
Cons of proselint
- Written in Python, which may be slower than Rust-based typos
- Less frequent updates and maintenance compared to typos
- More complex setup and configuration
Code Comparison
proselint:
def check(text):
"""Check the text."""
return lint(text)
def lint(text):
"""Lint the text."""
errors = []
for check in checks:
errors.extend(check(text))
return errors
typos:
pub fn check(text: &str) -> Vec<Typo> {
let mut typos = Vec::new();
for word in text.split_whitespace() {
if let Some(correction) = dictionary.correct(word) {
typos.push(Typo::new(word, correction));
}
}
typos
}
Summary
proselint offers more comprehensive writing analysis, focusing on style and clarity across multiple languages. However, it may be slower and requires more setup than typos. typos, being Rust-based, likely offers better performance and simpler usage, but focuses primarily on spelling corrections. The choice between the two depends on whether you need in-depth writing analysis or quick, efficient spell-checking.
Naive linter for English prose
Pros of write-good
- Focuses on writing style and clarity, not just spelling
- Provides suggestions for improving sentence structure and word choice
- Can be used as a command-line tool or Node.js module
Cons of write-good
- Limited to English language analysis
- May produce false positives for stylistic choices
- Less actively maintained compared to typos
Code Comparison
write-good:
var writeGood = require('write-good');
var suggestions = writeGood('So the cat was stolen.');
console.log(suggestions);
typos:
use typos::Typos;
let typos = Typos::new();
let corrections = typos.check("This is a sentance.");
println!("{:?}", corrections);
Key Differences
- write-good focuses on writing style and grammar, while typos primarily targets spelling errors
- typos is written in Rust, offering potential performance benefits for large-scale checks
- write-good provides more detailed suggestions for improving writing, whereas typos is more focused on identifying and correcting misspellings
- typos supports multiple languages, while write-good is limited to English
- write-good can be easily integrated into Node.js projects, while typos is more suitable for Rust-based applications or as a standalone tool
The pluggable natural language linter for text and markdown.
Pros of textlint
- More comprehensive text linting capabilities, including grammar and style checks
- Highly extensible with a large ecosystem of plugins
- Supports multiple languages and file formats
Cons of textlint
- Slower performance due to its JavaScript-based implementation
- More complex setup and configuration process
- Steeper learning curve for creating custom rules
Code Comparison
textlint:
module.exports = {
rules: {
"no-todo": true,
"max-comma": { max: 3 },
"spellcheck-tech-word": true
}
};
typos:
[default]
extend-ignore-re = [
"\\b(?i)THeriAL\\b",
]
While textlint offers more advanced linting capabilities and extensibility, typos focuses specifically on spell-checking and typo detection with a simpler configuration. textlint provides a wide range of customizable rules and plugins, making it suitable for complex text analysis tasks. On the other hand, typos is written in Rust, offering better performance and a more straightforward setup process for basic spell-checking needs. The choice between the two depends on the specific requirements of the project, with textlint being more suitable for comprehensive text linting and typos excelling in fast and efficient typo detection.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
typos
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
- Reference
- FAQ
- Comparison with other spell checkers
- Projects using typos
- Benchmarks
- Design
- Contribute
- CHANGELOG
Install
Download a pre-built binary (installable via gh-install).
Or use rust to install:
cargo install typos-cli
Or use Homebrew to install:
brew install typos-cli
Or use Conda to install:
conda install typos
Or use Pacman to install:
sudo pacman -S typos
Getting Started
Most commonly, you'll either want to see what typos are available with
typos
Or have them fixed
typos --write-changes
typos -w
If there is any ambiguity (multiple possible corrections), typos
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 _typos.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 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 typos --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
- typos-lsp (Language Server Protocol server)
Custom
typos
provides several building blocks for custom native integrations
-
reads fromstdin
,--write-changes
will be written tostdout
--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:
# Read file from stdin, write corrected version to stdout
typos - --write-changes
# Creates a diff of what would change
typos dir/file --diff
# Fully programmatic control
typos dir/file --format json
Debugging
You can see what the effective config looks like by running
typos --dump-config -
You can then see how typos is processing your project with
typos --files
typos --identifiers
typos --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 typos --files
?
If not, check your config with typos --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 typos --identifiers
or the word show up in typos --words
?
If not, it might be subject to one of typos' heuristics for
detecting non-words (like hashes) or
unambiguous words (like words after a \
escape).
If it is showing up, likely 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.
- To correct it locally, see also our False Positives documentation.
- To contribute your correction, see Contribute
Top Related Projects
Catch insensitive, inconsiderate writing
:pencil: A markup-aware linter for prose built with speed and extensibility in mind.
A linter for prose.
Naive linter for English prose
The pluggable natural language linter for text and markdown.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot