Custom Style Guide

Customizing the style guide is a great way to ensure that Hyperlint provides the most accurate and helpful feedback for changes to your documentation.

The style guide is a series of YAML files that Hyperlint uses to: (a) find errors in the content (b) provide recommendations on how to improve the content.

Hyperlint does this automatically for you.

Updating the style guide means placing several files in the .hyperlint directory of your repository.

Customizing the vocabulary

There are two files that you can use to customize the vocabulary used by Hyperlint:

Accepted vocabulary

These are the words that Hyperlint will enforce specific spelling for. Capitalization matters!

The file needs to be located at: .hyperlint/styles/config/vocabularies/hyperlint/accept.txt

Example contents:

Hyperlint
APIs

Rejected vocabulary

These are the words that Hyperlint will reject entirely from your documentation, alerting whenever they are present.

The file needs to be located at: .hyperlint/styles/config/vocabularies/hyperlint/reject.txt

Example contents:

Bad Word
Bad Word or phrase

Customizing style guide rules

Rules must live in the .hyperlint/styles/hyperlint directory and must have a .yml extension.

These rules follow the Vale style guide rule format.

Here's an example:

filename: .hyperlint/styles/hyperlint/RemoveVale.yml

Contents:

extends: existence
ignorecase: true
level: warning
message: Consider removing '%s'
tokens:
  - blah
  - style-a-rific

Using an existing Vale style guide setup

Under the hood, Hyperlint uses the vale style guide to provide some of it's style guide rules. You can leverage your existing Vale setup. No additional configuration is needed, if you have a .vale.ini file in the home directory of your GitHub repository, Hyperlint will automatically pick it up and use the contents.