markdownlint
Advanced tools
A Node.js style checker and lint tool for Markdown/CommonMark files.
markdownlint is a Node.js package that provides a linter for Markdown files. It helps ensure that Markdown files adhere to a consistent style and are free from common errors. The package can be used programmatically or via the command line, and it supports custom rules and configurations.
Linting Markdown Files
This feature allows you to lint Markdown files to ensure they follow specified rules. The code sample demonstrates how to lint a file named 'README.md' with a custom configuration that disables the 'MD013' rule.
const markdownlint = require('markdownlint');
const options = {
files: [ 'README.md' ],
config: {
'default': true,
'MD013': false
}
};
markdownlint(options, function callback(err, result) {
if (!err) {
console.log(result.toString());
}
});Custom Rules
This feature allows you to define and use custom rules for linting. The code sample shows how to include custom rules from a file named 'custom-rules.js' and apply them to 'README.md'.
const markdownlint = require('markdownlint');
const customRules = require('./custom-rules');
const options = {
files: [ 'README.md' ],
customRules: customRules
};
markdownlint(options, function callback(err, result) {
if (!err) {
console.log(result.toString());
}
});Command Line Interface
markdownlint can be used via the command line to lint files. The code sample demonstrates how to lint 'README.md' using a configuration file named '.markdownlint.json'.
markdownlint README.md --config .markdownlint.jsonremark-lint is a Markdown code style linter built on the remark processor. It is highly customizable and can be extended with plugins. Compared to markdownlint, remark-lint offers a more modular approach and integrates well with the unified ecosystem.
markdown-it is a Markdown parser that can be extended with plugins to add linting capabilities. While it is primarily a parser, its extensibility allows for custom linting rules. It is more flexible but requires additional setup compared to markdownlint.
markdownlint-cli is a command-line interface for markdownlint. It provides similar functionality to markdownlint but is specifically designed for use in the command line. It is a good choice if you prefer a CLI tool over a programmatic API.
A Node.js style checker and lint tool for Markdown/CommonMark files.
npm install markdownlint --save-dev
The Markdown markup language is designed to be easy to read, write, and understand. It succeeds - and its flexibility is both a benefit and a drawback. Many styles are possible, so formatting can be inconsistent; some constructs don't work well in all parsers and should be avoided.
markdownlint is a static analysis tool for
Node.js with a library of rules to enforce standards and consistency
for Markdown files. It was inspired by - and heavily influenced by - Mark
Harrison's markdownlint for Ruby. The initial rules, rule
documentation, and test cases came from that project.
markdownlint uses the micromark parser and honors the
CommonMark specification for Markdown. It additionally supports
popular GitHub Flavored Markdown (GFM) syntax like autolinks and tables
as well as directives, footnotes, and math syntax - all implemented by
micromark extensions.
The following specifications are considered authoritative in cases of ambiguity:
markdownlint demo, an interactive, in-browser
playground for learning and exploring.
See Rules.md for more details.
In addition to built-in rules, custom rules can be used to address
project-specific requirements. To find community-developed rules use
keyword markdownlint-rule on npm.
To implement your own rules, refer to CustomRules.md.
Tags group related rules and can be used to enable/disable multiple rules at once.
accessibility - MD045atx - MD018, MD019atx_closed - MD020, MD021blank_lines - MD012, MD022, MD031, MD032, MD047blockquote - MD027, MD028bullet - MD004, MD005, MD007, MD032code - MD014, MD031, MD038, MD040, MD046, MD048emphasis - MD036, MD037, MD049, MD050hard_tab - MD010headings - MD001, MD003, MD018, MD019, MD020, MD021,
MD022, MD023, MD024, MD025, MD026, MD036, MD041, MD043hr - MD035html - MD033images - MD045, MD052, MD053, MD054indentation - MD005, MD007, MD027language - MD040line_length - MD013links - MD011, MD034, MD039, MD042, MD051, MD052, MD053,
MD054ol - MD029, MD030, MD032spaces - MD018, MD019, MD020, MD021, MD023spelling - MD044table - MD055, MD056, MD058ul - MD004, MD005, MD007, MD030, MD032url - MD034whitespace - MD009, MD010, MD012, MD027, MD028, MD030,
MD037, MD038, MD039Text passed to markdownlint is parsed as Markdown, analyzed, and any
issues reported. Two kinds of text are ignored by most rules:
options.frontMatter below)Rules can be enabled, disabled, and configured via options.config
(described below) to define the expected behavior for a set of inputs.
To enable or disable rules at a particular location within a file, add
one of these markers to the appropriate place (HTML comments don't
appear in the final markup):
<!-- markdownlint-disable --><!-- markdownlint-enable --><!-- markdownlint-disable-line --><!-- markdownlint-disable-next-line --><!-- markdownlint-disable MD001 MD005 --><!-- markdownlint-enable MD001 MD005 --><!-- markdownlint-disable-line MD001 MD005 --><!-- markdownlint-disable-next-line MD001 MD005 --><!-- markdownlint-capture --><!-- markdownlint-restore -->For example:
<!-- markdownlint-disable-next-line no-space-in-emphasis -->
space * in * emphasis
Or:
space * in * emphasis <!-- markdownlint-disable-line no-space-in-emphasis -->
Or:
<!-- markdownlint-disable no-space-in-emphasis -->
space * in * emphasis
<!-- markdownlint-enable no-space-in-emphasis -->
To temporarily disable rule(s), then restore the former configuration:
<!-- markdownlint-capture -->
<!-- markdownlint-disable -->
any violations you want
<!-- markdownlint-restore -->
The initial configuration is captured by default (as if every document
began with <!-- markdownlint-capture -->), so the pattern above can
be expressed more simply:
<!-- markdownlint-disable -->
any violations you want
<!-- markdownlint-restore -->
Changes take effect starting with the line a comment is on, so the following has no effect:
space * in * emphasis <!-- markdownlint-disable --> <!-- markdownlint-enable -->
To apply changes to an entire file regardless of where the comment is located, the following syntax is supported:
<!-- markdownlint-disable-file --><!-- markdownlint-enable-file --><!-- markdownlint-disable-file MD001 --><!-- markdownlint-enable-file MD001 -->This can be used to "hide" markdownlint comments at the bottom of a file.
In cases where it is desirable to change the configuration of one or more rules for a file, the following more advanced syntax is supported:
<!-- markdownlint-configure-file { options.config JSON } -->For example:
<!-- markdownlint-configure-file { "hr-style": { "style": "---" } } -->
or
<!-- markdownlint-configure-file
{
"hr-style": {
"style": "---"
},
"no-trailing-spaces": false
}
-->
These changes apply to the entire file regardless of where the comment is
located. Multiple such comments (if present) are applied top-to-bottom. By
default, content of markdownlint-configure-file is assumed to be JSON, but
options.configParsers can be used to support
alternate formats.
Asynchronous API via import { lint } from "markdownlint/async":
/**
* Lint specified Markdown files.
*
* @param {Options | null} options Configuration options.
* @param {LintCallback} callback Callback (err, result) function.
* @returns {void}
*/
function lint(options, callback) { ... }
Synchronous API via import { lint } from "markdownlint/sync":
/**
* Lint specified Markdown files.
*
* @param {Options | null} options Configuration options.
* @returns {LintResults} Results object.
*/
function lint(options) { ... }
Promise API via import { lint } from "markdownlint/promise":
/**
* Lint specified Markdown files.
*
* @param {Options | null} options Configuration options.
* @returns {Promise<LintResults>} Results object.
*/
function lint(options) { ... }
Type: Object
Configures the function. All properties are optional, but at least one
of files or strings should be set to provide input.
Type: Object mapping String to Boolean | Object
Configures the rules to use.
Object keys are rule names/aliases; object values are the rule's configuration.
The value false disables a rule, true enables its default configuration,
and passing an object value customizes that rule. Setting the special default
rule to true or false includes/excludes all rules by default. In the absence
of a configuration object, all rules are enabled. Enabling or disabling a tag
name (ex: whitespace) affects all rules having that tag.
The default rule is applied first, then keys are processed in order from top
to bottom with later values overriding earlier ones. Keys (including rule names,
aliases, tags, and default) are not case-sensitive.
Example:
{
"default": true,
"MD003": { "style": "atx_closed" },
"MD007": { "indent": 4 },
"no-hard-tabs": false,
"whitespace": false
}
See .markdownlint.jsonc and/or .markdownlint.yaml for an example configuration object with all properties set to the default value.
Sets of rules (known as a "style") can be stored separately and loaded as JSON.
Example of referencing a built-in style from JavaScript:
const options = {
"files": [ "..." ],
"config": require("style/relaxed.json")
};
Example doing so from .markdownlint.json via extends (more on this below):
{
"extends": "markdownlint/style/relaxed"
}
See the style directory for more samples.
See markdownlint-config-schema.json
for the JSON Schema of the options.config
object.
See ValidatingConfiguration.md for ways to use the JSON Schema to validate configuration.
For more advanced scenarios, styles can reference and extend other styles.
The readConfig and readConfigSync functions can be used to read such
styles.
For example, assuming a base.json configuration file:
{
"default": true
}
And a custom.json configuration file:
{
"extends": "base.json",
"line-length": false
}
Then code like the following:
const options = {
"config": markdownlint.readConfigSync("./custom.json")
};
Merges custom.json and base.json and is equivalent to:
const options = {
"config": {
"default": true,
"line-length": false
}
};
Type: Optional Array of Function taking (String) and returning Object
Array of functions to parse the content of markdownlint-configure-file blocks.
As shown in the Configuration section, inline comments can be
used to customize the configuration object for a document. By
default, the JSON.parse built-in is used, but custom parsers can be specified.
Content is passed to each parser function until one returns a value (vs.
throwing an exception). As such, strict parsers should come before flexible
ones.
For example:
[ JSON.parse, require("toml").parse, require("js-yaml").load ]
Type: Array of Object
List of custom rules to include with the default rule set for linting.
Each array element should define a rule. Rules are typically exported by another package, but can be defined locally.
Example:
const extraRules = require("extraRules");
const options = {
"customRules": [ extraRules.one, extraRules.two ]
};
See CustomRules.md for details about authoring custom rules.
Type: Array of String
List of files to lint.
Each array element should be a single file (via relative or absolute path); globbing is the caller's responsibility.
Example: [ "one.md", "dir/two.md" ]
Type: RegExp
Matches any front matter found at the beginning of a file.
Some Markdown content begins with metadata; the default RegExp for
this option ignores common forms of "front matter". To match differently,
specify a custom RegExp or use the value null to disable the feature.
The default value:
/((^---[^\S\r\n\u2028\u2029]*$[\s\S]+?^---\s*)|(^\+\+\+[^\S\r\n\u2028\u2029]*$[\s\S]+?^(\+\+\+|\.\.\.)\s*)|(^\{[^\S\r\n\u2028\u2029]*$[\s\S]+?^\}\s*))(\r\n|\r|\n|$)/m
Ignores YAML, TOML, and JSON front matter such as:
---
layout: post
title: Title
---
Note: Matches must occur at the start of the file.
Type: Object implementing the file system API
In advanced scenarios, it may be desirable to bypass the default file system
API. If a custom file system implementation is provided, markdownlint will use
that instead of using node:fs.
Note: The only methods called are readFile and readFileSync.
Type: Boolean
Catches exceptions thrown during rule processing and reports the problem as a rule violation.
By default, exceptions thrown by rules (or the library itself) are unhandled
and bubble up the stack to the caller in the conventional manner. By setting
handleRuleFailures to true, exceptions thrown by failing rules will
be handled by the library and the exception message logged as a rule violation.
This setting can be useful in the presence of (custom) rules that encounter
unexpected syntax and fail. By enabling this option, the linting process
is allowed to continue and report any violations that were found.
Type: Array of Array of Function and plugin parameters
Specifies additional markdown-it plugins to use when
parsing input. Plugins can be used to support additional syntax and features for
advanced scenarios. Deprecated.
Each item in the top-level Array should be of the form:
[ require("markdown-it-plugin"), plugin_param_0, plugin_param_1, ... ]
Note that
markdown-itplugins are only called when themarkdown-itparser is invoked. None of the built-in rules use themarkdown-itparser, somarkdown-itplugins will only be invoked when one or more custom rules that use themarkdown-itparser are present.
Type: Boolean
Disables the use of HTML comments like <!-- markdownlint-enable --> to toggle
rules within the body of Markdown content.
By default, properly-formatted inline comments can be used to create exceptions
for parts of a document. Setting noInlineConfig to true ignores all such
comments.
Type: Number
Specifies which version of the result object to return (see the "Usage"
section below for examples).
Passing a resultVersion of 0 corresponds to the original, simple format
where each error is identified by rule name and line number. Deprecated
Passing a resultVersion of 1 corresponds to a detailed format where each
error includes information about the line number, rule name, alias, description,
as well as any additional detail or context that is available. Deprecated
Passing a resultVersion of 2 corresponds to a detailed format where each
error includes information about the line number, rule names, description, as
well as any additional detail or context that is available. Deprecated
Passing a resultVersion of 3 corresponds to the detailed version 2 format
with additional information about how to fix automatically-fixable errors. In
this mode, all errors that occur on each line are reported (other versions
report only the first error for each rule). This is the default behavior.
Type: Object mapping String to String
Map of identifiers to strings for linting.
When Markdown content is not available as files, it can be passed as
strings. The keys of the strings object are used to identify each
input value in the result summary.
Example:
{
"readme": "# README\n...",
"changelog": "# CHANGELOG\n..."
}
Type: Function taking (Error, Object)
Standard completion callback.
Type: Object
Call result.toString() for convenience or see below for an example of the
structure of the result object. Passing the value true to toString()
uses rule aliases (ex: no-hard-tabs) instead of names (ex: MD010).
The options.config configuration object is simple and can be stored in a file
for readability and easy reuse. The readConfig and readConfigSync functions
load configuration settings and support the extends keyword for referencing
other files (see above).
By default, configuration files are parsed as JSON (and named
.markdownlint.json). Custom parsers can be provided to handle other formats
like JSONC, YAML, and TOML.
Asynchronous API via import { readConfig } from "markdownlint/async":
/**
* Read specified configuration file.
*
* @param {string} file Configuration file name.
* @param {ConfigurationParser[] | ReadConfigCallback} [parsers] Parsing function(s).
* @param {Object} [fs] File system implementation.
* @param {ReadConfigCallback} [callback] Callback (err, result) function.
* @returns {void}
*/
function readConfig(file, parsers, fs, callback) { ... }
Synchronous API via import { readConfig } from "markdownlint/sync":
/**
* Read specified configuration file.
*
* @param {string} file Configuration file name.
* @param {ConfigurationParser[]} [parsers] Parsing function(s).
* @param {Object} [fs] File system implementation.
* @returns {Configuration} Configuration object.
*/
function readConfig(file, parsers, fs) { ... }
Promise API via import { readConfig } from "markdownlint/promise":
/**
* Read specified configuration file.
*
* @param {string} file Configuration file name.
* @param {ConfigurationParser[]} [parsers] Parsing function(s).
* @param {Object} [fs] File system implementation.
* @returns {Promise<Configuration>} Configuration object.
*/
function readConfig(file, parsers, fs) { ... }
Type: String
Location of configuration file to read.
The file is resolved relative to the current working directory. If an
extends key is present once read, its value will be resolved as a path
relative to file and loaded recursively. Settings from a file referenced by
extends are applied first, then those of file are applied on top (overriding
any of the same keys appearing in the referenced file). If either the file or
extends path begins with the ~ directory, it will act as a placeholder for
the home directory.
Type: Optional Array of Function taking (String) and returning Object
Array of functions to parse configuration files.
The contents of a configuration file are passed to each parser function until one of them returns a value (vs. throwing an exception). Consequently, strict parsers should come before flexible parsers.
For example:
[ JSON.parse, require("toml").parse, require("js-yaml").load ]
Type: Optional Object implementing the file system API
In advanced scenarios, it may be desirable to bypass the default file system
API. If a custom file system implementation is provided, markdownlint will use
that instead of invoking node:fs.
Note: The only methods called are readFile, readFileSync, access, and
accessSync.
Type: Function taking (Error, Object)
Standard completion callback.
Type: Object
Configuration object.
Rules that can be fixed automatically include a fixInfo property which is
outlined in the documentation for custom rules.
To apply fixes consistently, the applyFix/applyFixes methods may be used via
import { applyFix, applyFixes } from "markdownlint":
/**
* Applies the specified fix to a Markdown content line.
*
* @param {string} line Line of Markdown content.
* @param {RuleOnErrorFixInfo} fixInfo RuleOnErrorFixInfo instance.
* @param {string} [lineEnding] Line ending to use.
* @returns {string | null} Fixed content or null if deleted.
*/
function applyFix(line, fixInfo, lineEnding = "\n") { ... }
/**
* Applies as many of the specified fixes as possible to Markdown content.
*
* @param {string} input Lines of Markdown content.
* @param {RuleOnErrorInfo[]} errors RuleOnErrorInfo instances.
* @returns {string} Fixed content.
*/
function applyFixes(input, errors) { ... }
Invoking applyFixes with the results of a call to lint can be done like so:
import { applyFixes } from "markdownlint";
import { lint as lintSync } from "markdownlint/sync";
const results = lintSync({ "strings": { "content": original } });
const fixed = applyFixes(original, results.content);
To get the semantic version of the library, the getVersion method
can be used:
/**
* Gets the (semantic) version of the library.
*
* @returns {string} SemVer string.
*/
function getVersion() { ... }
Invoking getVersion is simple:
import { getVersion } from "markdownlint";
// Displays the library version
console.log(getVersion());
Invoke lint and use the result object's toString method:
import { lint as lintAsync } from "markdownlint/async";
const options = {
"files": [ "good.md", "bad.md" ],
"strings": {
"good.string": "# good.string\n\nThis string passes all rules.",
"bad.string": "#bad.string\n\n#This string fails\tsome rules."
}
};
lintAsync(options, function callback(error, results) {
if (!error && results) {
console.log(results.toString());
}
});
Output:
bad.string: 3: MD010/no-hard-tabs Hard tabs [Column: 19]
bad.string: 1: MD018/no-missing-space-atx No space after hash on atx style heading [Context: "#bad.string"]
bad.string: 3: MD018/no-missing-space-atx No space after hash on atx style heading [Context: "#This string fails some rules."]
bad.string: 1: MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "#bad.string"]
bad.md: 3: MD010/no-hard-tabs Hard tabs [Column: 17]
bad.md: 1: MD018/no-missing-space-atx No space after hash on atx style heading [Context: "#bad.md"]
bad.md: 3: MD018/no-missing-space-atx No space after hash on atx style heading [Context: "#This file fails some rules."]
bad.md: 1: MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "#bad.md"]
Or as a synchronous call:
import { lint as lintSync } from "markdownlint/sync";
const results = lintSync(options);
console.log(results.toString());
To examine the result object directly via a Promise-based call:
import { lint as lintPromise } from "markdownlint/promise";
const results = await lintPromise(options);
console.dir(results, { "colors": true, "depth": null });
Output:
{
"good.md": [],
"bad.md": [
{ "lineNumber": 3,
"ruleNames": [ "MD010", "no-hard-tabs" ],
"ruleDescription": "Hard tabs",
"ruleInformation": "https://github.com/DavidAnson/markdownlint/blob/v0.0.0/doc/md010.md",
"errorDetail": "Column: 17",
"errorContext": null,
"errorRange": [ 17, 1 ] },
{ "lineNumber": 1,
"ruleNames": [ "MD018", "no-missing-space-atx" ],
"ruleDescription": "No space after hash on atx style heading",
"ruleInformation": "https://github.com/DavidAnson/markdownlint/blob/v0.0.0/doc/md018.md",
"errorDetail": null,
"errorContext": "#bad.md",
"errorRange": [ 1, 2 ] },
{ "lineNumber": 3,
"ruleNames": [ "MD018", "no-missing-space-atx" ],
"ruleDescription": "No space after hash on atx style heading",
"ruleInformation": "https://github.com/DavidAnson/markdownlint/blob/v0.0.0/doc/md018.md",
"errorDetail": null,
"errorContext": "#This file fails\tsome rules.",
"errorRange": [ 1, 2 ] },
{ "lineNumber": 1,
"ruleNames": [ "MD041", "first-line-heading", "first-line-h1" ],
"ruleDescription": "First line in a file should be a top-level heading",
"ruleInformation": "https://github.com/DavidAnson/markdownlint/blob/v0.0.0/doc/md041.md",
"errorDetail": null,
"errorContext": "#bad.md",
"errorRange": null }
]
}
Integration with the gulp build system is
straightforward: gulpfile.cjs.
Integration with the Grunt build system is similar:
Gruntfile.cjs.
markdownlint also works in the browser.
Generate normal and minified scripts with:
npm run build-demo
Then reference the markdownlint-browser script:
<script src="demo/markdownlint-browser.min.js"></script>
And call it like so:
const options = {
"strings": {
"content": "Some Markdown to lint."
}
};
const results = globalThis.markdownlint.lintSync(options).toString();
For ideas how to integrate markdownlint into your workflow, refer to the
following projects or one of the tools in the Related section:
For more advanced integration scenarios:
See CONTRIBUTING.md for more information.
See ReleaseProcess.md for more information.
See CHANGELOG.md.
0.37.0
FAQs
A Node.js style checker and lint tool for Markdown/CommonMark files.
The npm package markdownlint receives a total of 666,630 weekly downloads. As such, markdownlint popularity was classified as popular.
We found that markdownlint demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.