Convert Figma logo to code with AI

crate-ci logotypos

Source code spell checker

2,472
94
2,472
95

Top Related Projects

4,798

Catch insensitive, inconsiderate writing

4,388

: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:

  1. Install Typos:

    cargo install typos-cli
    
  2. Run Typos on your project:

    typos
    
  3. To automatically fix typos:

    typos --write-changes
    
  4. 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

4,798

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.

4,388

: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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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

Screenshot

codecov Documentation License Crates Status

Dual-licensed under MIT or Apache 2.0

Documentation

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

Custom

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:

# 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.