Code Spell Checker for Visual Studio Code: Source-Word Review

Why the Code Spell Checker Extension Exists

Code Spell Checker addresses a narrow problem that ordinary prose spell checking handles poorly: source files contain identifiers, filenames, configuration keys, package names, and project-specific words that are absent from a general dictionary. The README says the extension works with code and documents, and its stated goal is to catch common spelling errors while keeping false positives low. That goal explains why it is designed around dictionaries and configuration rather than broad grammatical analysis.

The intended users are developers and technical writers who edit TypeScript, JavaScript, text, and related files in VS Code. A misspelled variable or documentation term can receive a squiggly underline while the editor is open. This is useful as a lightweight review aid, especially when a repository has many files and regular language checking would spend time on valid code terms.

The project does not claim to understand program meaning or validate identifiers semantically. Its documented behavior is lexical: a word that is not in the loaded dictionary files is treated as a spelling candidate. This boundary matters. A valid domain term may still be flagged until it is added to the project configuration or supplied by an installed dictionary extension. A real grammatical error that happens to contain known words may not be caught.

How VS Code Gets Diagnostics from the Extension

The repository is a TypeScript project packaged as a VS Code extension. Its `package.json` identifies the extension package as `code-spell-checker`, declares `onStartupFinished` as an activation event, and points to `./packages/client/dist/extension.cjs` as the main entry point. The repository layout also contains a `packages` directory, sample configurations, dictionaries, and TypeScript build files. Together, these entries indicate a client extension backed by a larger packaged implementation rather than a single standalone script.

At startup, the extension can register language-oriented editing behavior in VS Code. For a loaded TypeScript, JavaScript, or text file, the README documents the visible result: words not present in the dictionary files receive a squiggly underline. VS Code supplies the editing surface, diagnostics presentation, cursor position, and Quick Fix action. The extension supplies the spelling decision and suggestions.

Configuration is part of this flow. The repository includes `cspell.json`, `cspell.config.yaml`, sample configuration files, and files for custom dictionaries. The README specifically documents the setting `cSpell.language`, with US English as the default and an example change to `en-GB`. The package metadata gives the extension a workspace extension kind and states that JavaScript configuration files are not loaded in untrusted workspaces. In virtual workspaces, JavaScript configuration cannot be loaded, and configuration dependent on `node_modules` will not be loaded. Those limits directly affect which dictionary rules are available.

Installing Code Spell Checker and Reviewing a Misspelling

The README gives an editor installation procedure rather than a shell installation command. Open VS Code, press `F1`, type `ext`, select the extension search view, search for `code-spell-checker`, install it, and reload the window. The reader should see the Code Spell Checker extension available from the VS Code Extensions view before installing it.

After reloading, open a supported source file. The README describes a squiggly underline for a word that is not in the dictionary files. Place the cursor in the flagged word to inspect suggestions. The documented ways to open them are the lightbulb in the left margin and the VS Code Quick Fix editor action. The keyboard shortcuts shown in the README are `⌘`+`.` on Mac and `Ctrl`+`.` on PC.

For a British English dictionary, the README instructs users to change the language setting. The setting key is `cSpell.language`, and the documented values are `en` and `en-GB`. This can be applied through the editor's settings interface. The repository includes language dictionary extensions for additional languages, so the base extension and its dictionary coverage are related but separate pieces.

The source repository itself declares `[email protected]` as its package manager and requires Node `>=22.20.0` for development. Those values describe repository development prerequisites, not a separate installation path for ordinary users who install the packaged extension through VS Code.

Dictionary Coverage, Configuration, and Project Vocabulary

The extension's accuracy depends on the words available to it. A project can contain proprietary names, abbreviations, generated identifiers, and terms that are correct for its domain but absent from a general dictionary. The repository includes `cspell.json`, `cspell.config.yaml`, sample dictionaries, and files such as `cspell-words.txt`, which show that configuration and vocabulary are first-class project concerns rather than incidental editor preferences.

The README documents English US and English GB support and links to a large set of separate dictionary extensions. This design gives users a choice between the core package and language-specific packages, but it also means that seeing an unexpected underline does not prove that the word is misspelled. The first check is whether the appropriate language dictionary is installed and whether project vocabulary has been added to configuration.

Configuration format is another boundary. The package metadata says that JavaScript configuration files are not loaded in untrusted workspaces. It also says that virtual workspaces cannot load CSpell configuration from JavaScript and that configuration relying on `node_modules` will not be loaded. JSON, JSONC, or YAML configuration is therefore the safer supported path in those workspace types, according to the package metadata description.

The README's emphasis on a low false-positive rate is a project goal, not a measured guarantee in the repository description. No benchmark, accuracy percentage, or language-specific false-positive rate is documented there. Engineers should judge the extension against their own vocabulary and file types rather than treating any particular warning rate as established.

Where Code Spell Checker Falls Short

The largest limitation is scope. Code Spell Checker checks spelling against dictionaries, but the README does not document semantic validation, type checking, grammar analysis, or project-aware recognition of every valid identifier. It can flag a package name that is not in the dictionary. It cannot be assumed to detect a misspelling whose token happens to be recognized as another word.

Its configuration also varies with workspace trust and workspace type. JavaScript configuration is unavailable in untrusted workspaces, while virtual workspaces cannot load JavaScript configuration or configuration that depends on `node_modules`. Teams that centralize all spelling rules in JavaScript and expect identical behavior across remote, virtual, and untrusted environments will need to account for those restrictions.

There is a maintenance and compatibility cost for developers building from source. The package metadata lists `vscode` `^1.104.0`, Node `>=22.20.0`, `engineStrict` set to `true`, and a package manager declaration for `[email protected]`. The repository is not archived, but compatibility still needs to be inspected when changing the development toolchain.

The package metadata identifies the project as `GPL-3.0-or-later`, while the repository description classifies the license as custom because GitHub could not classify it. Anyone evaluating distribution or integration should inspect the repository `LICENSE` file directly. This review does not provide legal interpretation of the license.

Choosing Between an Editor Extension and a Repository CSpell Workflow

Code Spell Checker is the editor-oriented choice. Its documented workflow is to install the VS Code extension, load a file, receive inline underlines, and request suggestions through VS Code's Quick Fix. That fits developers who want feedback while moving through code, and it keeps the action inside the editor rather than requiring a separate review command.

The repository and README also point to the broader CSpell ecosystem, including CSpell-related sponsorship links and configuration files. A repository-level CSpell workflow would be the alternative when checking needs to be repeatable outside one editor, but the available documentation does not specify the exact CLI command or its configuration surface. That difference should be verified from the relevant CSpell documentation before selecting it.

The extension is therefore better suited to interactive editing, while a repository-level CSpell setup is the more appropriate concept for standardized checks in scripts or continuous integration. Neither should be treated as a semantic linter. The choice turns on where the check must run, which workspace types are supported, and how much dictionary and configuration ownership the team needs.

Editorial conclusion

Adopt Code Spell Checker when you want spelling diagnostics inside VS Code and can maintain dictionary configuration for project vocabulary. Do not choose it as a complete semantic or grammar checker. Verify first that your workspace configuration, custom words, and dictionary extensions match the languages and files you expect it to process.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. streetsidesoftware/vscode-spell-checker on GitHub