Most software developers are familiar with tools to lint their source code. Linting code is the process of checking your code against a defined set of rules to help keep a consistent naming convention, prevent common mistakes, and anti-patterns in other aspects of your code, provided the requirement can be expressed in configuration understood by your linting tool.
What if you could lint your documentation as well? We are all familiar with spell checking tools and you might already use, like Grammarly. But, those tools are only available in your editing environment and not a part of the normal workflows related to source code.
Documentation as code is a common recommendation for software developers. When we treat our documentation as code, we also want to run all the automated checks we run against source code on our documentation as well.
With Vale you can lint the documentation in your source code repository.
Vale is a command-line and open-source linting tool that allows developers to define and apply custom rules for documentation/editorial style guides. Incorporating Vale in documentation helps to detect errors and provides error-fixing suggestions.
Here are other ways to leverage Vale:
It is backed and used by companies like Google, Microsoft, GitHub, and RedHat, and it has a collection of packages ready for you to implement. Using Vale provides flexibility because it allows developers to create their style guides from scratch or use its config generator. Using the config generator of Vale, you can generate configuration files for your style guide with existing base and supplementary style implementations.

Running a linter on your documentation enforces the use of your documentation style guides. It helps:
Vale is commonly used to help ensure documentation consistency, whether for a software project, a technical manual, or any other type of documentation. Vale can flag any inconsistencies or deviations from the established style guide. This helps to ensure that all documentation is written in a consistent tone and style, making it easier for readers to understand.
Vale can also help improve the clarity of technical writing by flagging complex sentences, jargon, and other issues that may make the writing more difficult to understand. This can be particularly useful for technical writers communicating complex concepts to various audiences.Vale can also help catch common mistakes like passive voice, repetitive phrasing, or overly complex sentences.
Vale is highly customizable and can also be used to define custom writing rules and styles. There are established writing rules and styles defined by several large companies you can also choose to use. The availability of established rulesets makes Vale a powerful tool allowing you to quickly get started. But, if you want to establish your style guide and writing standards, that's also perfectly fine. You can adjust an established set of rules and styles with relative ease. By defining a set of rules and styles specific to your needs, you can ensure that all written materials adhere to your established standards.
If you want to use Vale in your project, there are some steps you need to take. The configuration you need to add describes to Vale what to check against which rules.
Here’s an example of Vale configuration from one of our SDK repositories.
.jsx files to .js
b. Supported languages
c. Add ignores (if necessary)Once you configure Vale on your project, you probably want your CI environment to also lint your documentation. At Stream we use GitHub actions for our CI execution environment. Here’s an example of how we configure Vale on one of our SDKs.
If you are unfamiliar with GitHub Actions, make sure to check it out, especially if you host your Git repositories on GitHub. To learn more about GitHub Actions,click here.
on trigger, for us on every opened PR)ubuntu-latest (even for Swift, as it’s preinstalled there)vale-action step (link to it on Github for reference)By now you have Vale configured on your project and perhaps even your CI environment. You can run Vale from the command line, but integrating Vale with your favorite code editor or IDE will be a huge help. Vale has documentation on several commonly used editors and IDEs.
We will describe the steps you need to take to integrate Vale in any of JetBrains’ tools and Visual Studio Code. And to top it off, we spent some time on getting integration with Xcode working as well. Xcode is not supported out of the box by Vale, but by using a build phase and some scripting we were able to create a tight integration between Xcode and Vale.
To integrate Vale with any of JetBrain’s tools, you can use the Vale Plugin for IntelliJ IDEA. Here are the seven steps you must follow to install and use the plugin:
To integrate Vale with Visual Studio Code, you can use the Vale Server extension. Here are the six steps you must complete to install and use the extension:
To integrate Vale with Xcode we need to do some more work. There is not an Xcode plugin available at the moment allowing easy integration with Vale.But fortunately, the Vale tool itself is very flexible. Here’s how to integrate:
.styles folder of your repository containing your Xcode project..styles, create a file names: xcode-line.tmpl. The contents of this file should be:{{range .Files}}
{{- $path := .Path -}}
{{- range .Alerts -}}
{{$path}}:{{.Line}}:{{index .Span 0}}: {{.Severity}}: {{.Check}}:{{.Message}}
{{end -}}
{{end -}}
vale-linting.sh in the directory bin at the root of your project.
a. Change the directory in your terminal at the root of your project.
b. Run mkdir bin if the bin directory does not exist yet.
c. Next, run touch bin/vale-linting.sh.
d. Make sure your new script is executable by running: chmod +xu bin/vale-linting.sh.
e. Edit the vale-linting.sh file with your text editor of choice and make sure the contents of the file are:if ! which vale >/dev/null; then
if ! which brew >/dev/null; then # If it's not found, check the Homebrew location and update PATH when needed
if test -e "/usr/local/bin/brew"; then # Default Homebrew location (pre M1 era)
PATH="${PATH}:/usr/local/bin"
elif test -e "/opt/homebrew/bin/brew"; then # Default Homebrew location (M1 era)
PATH="${PATH}:/opt/homebrew/bin"
else
echo "warning: Homebrew not found at default location"
fi
fi
fi
if which vale >/dev/null; then
vale --output=./.styles/xcode-line.tmpl docusaurus
else
echo "warning: Vale not installed, download from https://vale.sh"
fi
f. Finally, add a custom build script step to your build target.
./bin/vale-lint.sh.Stream’s Swift Chat SDK has a working setup based on the above.
At Stream, we rely on Vale to catch a lot of the typical issues that creep into documentation. Not only does it allow us to lint our markdown files, it also lints the structured documentation comments in our sourcecode. Vale is optimized for speed and when made part of a build its runtime impact is negligible, but its value in catching typos and common errors is great. At Stream we consider Vale to be an important part of improving and maintaining the quality of our documentation.