A CLI tool to check the quality of writing in your project's markdown or plain text documentation.
This tool uses retext to check the quality of writing in your project's documentation using these plugins;
retext-equalitywarns on insensitive, inconsiderate language.retext-intensifywarns on filler, weasel and hedge words.remark-lintchecks for proper markdown formatting.retext-readabilitychecks the reading level of the whole document.retext-simplifywarns on complicated phrases.retext-spellchecks spelling against a US English dictionary and custom dictionary.
Install the tool globally with npm to use the CLI.
npm install -g quality-docsThe CLI accepts one argument which is a glob of the documentation files you want to check. For example, to recursively check every .md file in your project;
quality-docs {,**/}*.mdThe -s, --silent flag enables silent mode which mutes warnings. Fatal errors are displayed in silent mode.
The -c, --config flag passes in a JSON file with a custom config. The config is combined with default-config.json and the custom config overrides the defaults.
quality-docs {,**/}*.md --config custom-config.jsonThe override uses this format (without comments):
{
"dictionaries": "sparkart.dic", // Path to custom dictionary file, relative to config file
"rules": { // Turn rules on/off or change their severity
"filler": {"severity": "warn"},
"hedge": {"severity": "suggest"},
"list-item-content-indent": false,
"no-auto-link-without-protocol": false,
"retext-readability": {
"age": 18,
"minWords": 7,
"severity": "fatal"
},
"weasel": {"severity": "suggest"}
},
"ignore": [ // Words or phrases to ignore
"can",
"forward",
"found",
"start",
"started",
"up"
],
"noIgnore": [ // Words or phrases ignored by default to not ignore
"require",
"transmit"
]
}When used along with the config flag, the -i, --ignore flag adds a word to the config file's ignore list. Example;
$ quality-docs {,**/}*.md --config custom-config.json --ignore irregardless
Added 'irregardless' to ignore list. Don't forget to commit the changes to custom-config.json.The tool uses vfile-reporter to print a report of writing quality issues with their location and description. For example, a spelling error in README.md from line 76 column 119 to line 76 column 124 prints;
README.md
76:119-76:124 error thier is misspelled spellingBy default, quality-docs spell checks documents against a US English dictionary. To extend the built in dictionary with custom English terms related to your project(s), add a hunspell format .dic file to your project, and reference it with the customDictionary key in a custom config JSON file. See en_US-tech-industry.dic for an example. (Note: quality-docs uses the US English affix file to check for valid variants of dictionary words. Non-English characters or prefix/suffix rules are not supported.)
The quality-docs CLI ships with an opinionated configuration to improve your writing. If you want to override the defaults of the retext plugins used by this tool, we recommend one of these three options;
- Exclude documentation files from the glob argument.
- Use the
--configflag to pass in a JSON file with default configuration overrides. - Use
remark-message-controlmarks to turn on/off specific rules for individual documents or text nodes.
Here is a list of common confusing issues quality-docs flags, and how to resolve them;
If it's a common name, add it to a custom dictionary. If it isn't common or you don't want to add it to the dictionary, add it to the ignore array in a config override file.
Any non-dictionary terms in quotes are ignored. If the word is a literal value such as a variable name or package name, put it in backticks; `quality-docs`. If it's a made-up word or other literal representation of a non-dictionary term, use "buttonator" or 'buttonator'.
First, check the rules for formatting table cells in markdown. If everything is correct, check for empty table cells, which throw off the linter. Try adding content to blank cells; n/a or (none).
Try using the methods provided to change the default config to suit your preferences. If custom config doesn't resolve the problem, file an issue including the text of the markdown file you're checking and the error you're seeing in the output.
Open an issue to report bugs or ask questions. Open a PR to contribute. Run npm run test to make sure contributions pass the included tests.
