How To Detect Spelling Errors In Code With CSpell

Let tools catch spelling issues before Oxford graduates do

Photo by Sandy Millar on Unsplash

Not a paying Medium member? Click here to view this post as a normal Medium member!

Mistakes can happen to anyone. Spelling mistakes can easily happen when we are not fully focused while typing or we are maybe not fluent in a certain language. Typos are usually considered minor problems in software applications: a typo is usually at worst conceived as a minor annoyance to a user. Too many of those smaller mistakes can make a unprofessional impression, though.

If you are using tools like Microsoft Word or Google Docs you are familiar with spell checking. Even a decent spell checker will ensure a base minimum of quality, greatly reducing the likelihood for unintentionally introducing typos.

As developers we are used to automate processes and checks as much as possible. We are e.g. (hopefully!) writing tests to avoid retesting the whole application whenever we do a small change. ESLint is a popular linter for JavaScript / TypeScript projects that helps to enforce certain rules across the code base: e.g. forbidding certain features and enforcing name conventions. So why should we not make use of automation tools to find spelling mistakes in our code base?

Enter CSpell 🪄

CSpell is a spell checker for code. You can run it via CLI or install it as VS -Code extension. What I find even more useful is the ESLint plugin:

• Developers can use any common IDE (e.g. WebStorm, VS Code)
• Issues are shown while developing which helps to find issues before committing/reviewing them.
• Linting is typically not only done locally but also as part of Continuous Integration (e.g. using GitHub Workflows). By running ESLint as part of our CI workflow we reduce the likelihood that mistakes are caught before merging a pull request containing typos.

You can install it as a devDependency using npm:

npm install --save-dev cspell @cspell/eslint-plugin
# Run CSpell via CLI
cspell . -c cspell.config.yaml --no-progress --show-context

The ESLint plugin can checks all JavaScript and TypeScript files for spelling mistakes. The CSpell configuration can contain additional words which are valid (e.g. terms specific to your application such as code names). You can also ignore certain paths (e.g. specific files or build directories).

Now we have to register the plugin in the ESLint configuration file. In this case, we are enabling CSpell for all TypeScript files which are not test files (we do not care for typos in tests that much). You can customize how much CSpell should check (e.g. if you do not care for checking comments you can disable it). If you are introducing CSpell to a large project it might be harder to fix all mistakes at once: in that case, you use warning instead of error to incrementally adopt CSpell.

Do you have a monorepo (e.g. using Nx) with projects that should not be checked? Then you can disable the inherited ESLint rule explicitly.

{
  ...
  "@cspell/spellchecker": "off"
}

Some files will have words that would be flagged but you do not want to add them to the YAML configuration file? Then you can disable CSpell for a given line or an entire file.

/* eslint-disable @cspell/spellchecker */
// eslint-disable-next-line @cspell/spellchecker

Having too many or badly configured ESLint rules can slow down the linting process and thereby the developer experience. You can get an overview of your slowest ESLint rules by providing the TIMING=1 environment variable before executing the ESLint command.

TIMING=1 eslint pathToMyCode

Conclusion

Thanks for reading this short post about leveraging CSpell! CSpell helps us catch spelling issues while we are developing. Also, we benefit from reduced time to review PRs as developer hardly need to manually check for spelling issues if CSpell is taking care of that. Of course it cannot catch everything (e.g. it will not catch grammar mistakes) but is a small but important tool to help maintaining a clean code base.

Let me know in the comments about your experiences.