textlint: A Pluggable Linter for Natural Language, Built Like ESLint
textlint is the pluggable linter for natural language text.
At a glance
- What is it?
- textlint brings the ESLint model to prose: no bundled rules, npm-installed rule packages, and a config file that maps rule names to options. It targets Markdown and plain text out of the box, with plugins for HTML and other formats.
- Who is it for?
- Adopt textlint if you write or maintain Markdown documentation, blog posts, or plain text files and want linting that mirrors ESLint's rule and config model. It is not for you if you need out-of-the-box rules, since it ships with none, or if your primary content lives in formats without a maintained processor plugin.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Prose Has No Linter, So textlint Borrows ESLint's Shape
Code has linters that catch style violations, unused variables, and formatting slips. Natural language has spell checkers and grammar tools, but they are often monolithic and hard to extend. textlint fills that gap by applying the ESLint architecture to prose. The README states it plainly: textlint is similar to ESLint, but for natural language. The target user is a developer, technical writer, or documentation maintainer who already thinks in terms of lint rules and config files. If you have ever wanted to enforce 'no TODO comments' or 'no exclamation marks' across a Markdown repo, textlint gives you a structured way to do that, not a one-off script.
No Bundled Rules: The Core Design Trade-Off
The most important fact in the README is that textlint has no default rules. You install every rule separately via npm, for example textlint-rule-no-todo. This is a deliberate design choice, but it has consequences. On the plus side, the core stays small and you only load what you need. On the minus side, a fresh install lints nothing until you find and install rules. The README points to a wiki collection of rules, but that is a manual step. This is the same trade-off ESLint made in its early days, and it works if the rule ecosystem is healthy. For textlint, the rule list exists, but you must browse it yourself. The tool does not help you discover rules beyond the wiki link. That is a real friction point for new users.
How It Works: Config Files, Rule Packages, and Processor Plugins
textlint reads a .textlintrc file, which can be JSON, YAML, or JS, loaded via the rc-config-loader. The config maps rule names to either true, false, or an options object. For example, setting "no-todo": true enables that rule, while "no-todo": false disables it. You can also pass rule-specific options as an object, like {"key": "value"}. The CLI accepts --rule flags, which are equivalent to entries in the config file. For file formats beyond Markdown and plain text, you install a processor plugin, such as textlint-plugin-html, and list it under the "plugins" key in the config. The plugin then handles parsing that format. This separation of parser and rules mirrors ESLint's parser and rule split, and it keeps the core format-agnostic.
Getting Started: Commands and Configuration You Will Actually Run
The README gives a concrete path. First, install textlint and a rule locally: npm install --save-dev textlint textlint-rule-no-todo. Then run npx textlint --init to create a .textlintrc.json file. That file starts with the installed rule enabled, like {"rules": {"no-todo": true}}. Finally, lint a file with npx textlint ./README.md. You can also target directories or globs, but the README warns to quote globs, so npx textlint "docs/**" works as expected. The CLI has options for --fix, --dry-run, --ignore-path, and --debug. The --dry-run option is useful because it shows what --fix would change without modifying files, which is a safe way to test new rules. Node.js 20 or newer is required, so check your runtime before installing.
A Genuine Limitation: Scope Mismatch and Rule Discovery
textlint is the wrong tool if your text lives in formats without a maintained processor plugin. The README lists optional plugins for HTML, reStructuredText, AsciiDoc, Re:VIEW, and Org-mode, but these are third-party projects. If your format is not on that list, you must write a plugin or convert your files. Another limitation is rule quality. Since rules are separate npm packages, their quality and maintenance vary. The README does not rate or audit them. You might install a rule that is abandoned or that conflicts with another rule. The config file gives you control, but you have to do the vetting. Also, textlint lints text, not meaning. It cannot catch logical fallacies or factual errors. It is a style and convention checker, not a proofreader.
Alternative: ESLint Itself, With a Different Focus
The obvious alternative is not another natural language linter, but ESLint itself. ESLint is a code linter, not a prose linter, but many projects already use it for JavaScript and TypeScript. You could write custom ESLint rules to check comments or string literals, but that is awkward because ESLint parses code, not Markdown prose. A more direct alternative is a tool like Vale, which is a command-line prose linter with its own rule syntax and a different configuration model. Vale uses YAML-based styles and does not follow the npm package model. textlint's advantage is that rules are npm packages, so they integrate with your existing JavaScript toolchain and can be versioned and shared like code. Vale is a standalone binary with a different distribution model. The choice depends on whether you want npm-centric workflows or a self-contained tool.
Maintenance and Upgrade Cost: Active Releases and a Simple Upgrade Path
The repository shows regular releases, with v15.8.0 pushed on August 1, 2026, and prior versions in May 2026. That signals active maintenance. The upgrade cost is low because textlint uses semantic versioning, and the config format is stable. You update the textlint package and your rules independently. However, you must keep the core and rules in the same scope, local or global. The README warns that if you install textlint globally, you must install rules globally too. Mixing scopes causes resolution failures. This is a common pitfall, and it is a maintenance trap when you work across multiple projects. The MIT license means you can use it commercially without restriction, but you still need to check each rule's license because rules are separate packages. The project's own license is permissive, but the ecosystem is not a single legal entity.
Editorial conclusion
Adopt textlint if you write or maintain Markdown documentation, blog posts, or plain text files and want linting that mirrors ESLint's rule and config model. It is not for you if you need out-of-the-box rules, since it ships with none, or if your primary content lives in formats without a maintained processor plugin. Before adopting, verify that the rules you need exist on npm, that your Node version is 20 or newer, and that you install textlint and its rules in the same scope, local or global, to avoid resolution errors. The project is actively maintained, with a v15.8.0 release in August 2026, and its MIT license poses no obvious adoption barrier, but the real cost is rule discovery and configuration, not the tool itself.
Community notes