Top Related Projects
A mighty CSS linter that helps you avoid errors and enforce conventions.
Find and fix problems in your JavaScript code.
Prettier is an opinionated code formatter.
textlint is the pluggable linter for natural language text.
A Node.js style checker and lint tool for Markdown/CommonMark files.
Quick Overview
Remark-lint is a plugin for the remark Markdown processor that provides linting functionality. It helps maintain consistent Markdown formatting and style by checking for common issues and enforcing customizable rules.
Pros
- Highly customizable with a wide range of built-in rules
- Integrates seamlessly with the remark ecosystem
- Can be used as a CLI tool or programmatically
- Supports custom rule creation for specific needs
Cons
- Learning curve for configuring and customizing rules
- Some rules may be overly strict for certain use cases
- Performance can be impacted when using many rules on large documents
- Documentation for some advanced features could be more comprehensive
Code Examples
- Basic usage with remark:
import { remark } from 'remark';
import remarkLint from 'remark-lint';
import remarkPresetLintConsistent from 'remark-preset-lint-consistent';
const markdown = '# Hello world';
remark()
.use(remarkLint)
.use(remarkPresetLintConsistent)
.process(markdown)
.then((file) => {
console.log(file.messages);
});
- Using specific rules:
import { remark } from 'remark';
import remarkLint from 'remark-lint';
import remarkLintListItemIndent from 'remark-lint-list-item-indent';
remark()
.use(remarkLint)
.use(remarkLintListItemIndent, 'space')
.processSync('- Item\n - Subitem');
- Creating a custom rule:
import { lintRule } from 'unified-lint-rule';
import { visit } from 'unist-util-visit';
const remarkLintNoLongParagraphs = lintRule(
'remark-lint:no-long-paragraphs',
(tree, file) => {
visit(tree, 'paragraph', (node) => {
if (node.children.length > 100) {
file.message('Paragraph is too long', node);
}
});
}
);
export default remarkLintNoLongParagraphs;
Getting Started
To use remark-lint in your project:
- Install the necessary packages:
npm install remark remark-lint remark-preset-lint-recommended
- Create a configuration file (e.g.,
.remarkrc.js):
module.exports = {
plugins: [
require('remark-preset-lint-recommended'),
[require('remark-lint-list-item-indent'), 'space']
]
};
- Run remark-lint on your Markdown files:
npx remark . --use remark-lint
This setup will use the recommended preset and a custom rule for list item indentation.
Competitor Comparisons
A mighty CSS linter that helps you avoid errors and enforce conventions.
Pros of stylelint
- Broader scope: Covers CSS, SCSS, Less, and other CSS-like syntaxes
- Extensive rule set: Over 170 built-in rules for comprehensive linting
- Flexible configuration: Easily customizable through sharable configs and plugins
Cons of stylelint
- Steeper learning curve: More complex setup and configuration options
- Performance: Can be slower on large codebases due to its comprehensive nature
Code Comparison
stylelint configuration example:
{
"extends": "stylelint-config-standard",
"rules": {
"indentation": 2,
"color-hex-case": "lower"
}
}
remark-lint configuration example:
{
"plugins": [
"remark-preset-lint-recommended",
["remark-lint-list-item-indent", "space"]
]
}
Both tools offer powerful linting capabilities, but stylelint focuses on CSS and related syntaxes, while remark-lint is primarily for Markdown. stylelint provides a more comprehensive set of rules and broader language support, making it ideal for complex CSS projects. However, this comes at the cost of a steeper learning curve and potentially slower performance on large codebases. remark-lint, being more specialized for Markdown, offers a simpler setup and faster performance for its specific use case.
Find and fix problems in your JavaScript code.
Pros of ESLint
- Broader language support: JavaScript, TypeScript, and various frameworks
- Larger ecosystem with extensive plugins and configurations
- More comprehensive set of rules for code quality and style
Cons of ESLint
- Steeper learning curve for configuration and custom rule creation
- Can be slower for large projects due to its extensive rule set
- Primarily focused on JavaScript, less suitable for other file types
Code Comparison
ESLint configuration example:
{
"extends": "eslint:recommended",
"rules": {
"semi": ["error", "always"],
"quotes": ["error", "double"]
}
}
remark-lint configuration example:
{
"plugins": [
"remark-lint",
"remark-lint-list-item-indent"
]
}
Key Differences
- ESLint is primarily for JavaScript and related technologies, while remark-lint focuses on Markdown files
- ESLint offers more granular control over code style and quality, whereas remark-lint specializes in Markdown formatting and structure
- ESLint has a larger community and more frequent updates, but remark-lint is more lightweight and easier to set up for Markdown-specific projects
Use Cases
- Choose ESLint for JavaScript/TypeScript projects with complex linting requirements
- Opt for remark-lint when working primarily with Markdown files or documentation-heavy projects
Prettier is an opinionated code formatter.
Pros of Prettier
- Supports multiple languages (JavaScript, TypeScript, CSS, HTML, etc.)
- Opinionated formatting with minimal configuration options
- Integrates well with various editors and IDEs
Cons of Prettier
- Less flexible for custom formatting rules
- May not handle complex Markdown structures as effectively as Remark Lint
- Limited to code formatting, doesn't address content-related issues
Code Comparison
Prettier (JavaScript):
function example(a,b){
return a+b;
}
Remark Lint (Markdown):
# Heading
- List item 1
- List item 2
> Blockquote
Key Differences
- Prettier focuses on code formatting across multiple languages, while Remark Lint specializes in Markdown linting and formatting
- Remark Lint offers more granular control over Markdown-specific rules and structures
- Prettier aims for consistency with minimal configuration, whereas Remark Lint provides more customization options
Use Cases
- Choose Prettier for general code formatting across various languages in a project
- Opt for Remark Lint when working primarily with Markdown and requiring detailed control over document structure and style
Community and Ecosystem
- Both projects have active communities and regular updates
- Prettier has a larger user base due to its multi-language support
- Remark Lint benefits from the broader Remark ecosystem for Markdown processing
textlint is the pluggable linter for natural language text.
Pros of textlint
- More flexible and supports various text formats (Markdown, plain text, HTML, etc.)
- Extensive plugin ecosystem with many ready-to-use rules
- Supports multiple languages and has better internationalization features
Cons of textlint
- Steeper learning curve due to its flexibility and extensive configuration options
- May require more setup time compared to remark-lint's simpler approach
- Performance can be slower when using multiple plugins simultaneously
Code Comparison
textlint configuration:
{
"rules": {
"no-todo": true,
"max-comma": { "max": 3 },
"spellcheck-tech-word": true
}
}
remark-lint configuration:
{
"plugins": [
"remark-lint",
"remark-lint-no-todo",
["remark-lint-maximum-line-length", 80]
]
}
Both tools offer powerful linting capabilities for Markdown and other text formats. textlint provides more flexibility and supports a wider range of text types, making it suitable for complex documentation projects. remark-lint, on the other hand, is more focused on Markdown and offers a simpler setup process, which can be advantageous for projects primarily dealing with Markdown files. The choice between the two depends on the specific needs of your project, such as the variety of text formats you're working with and the level of customization required.
A Node.js style checker and lint tool for Markdown/CommonMark files.
Pros of markdownlint
- Wider language support, including JavaScript, TypeScript, and Ruby
- More extensive rule set with over 40 built-in rules
- Easier integration with popular text editors and IDEs
Cons of markdownlint
- Less flexible configuration options compared to remark-lint
- Slower performance for large files or projects
- Limited extensibility for custom rules
Code Comparison
markdownlint:
const markdownlint = require("markdownlint");
const options = {
files: ["README.md"],
config: {
"MD013": false,
"MD033": { "allowed_elements": ["br"] }
}
};
markdownlint(options, function callback(err, result) {
console.log(result.toString());
});
remark-lint:
const remark = require('remark');
const lint = require('remark-lint');
remark()
.use(lint)
.process('# Hello world!', function(err, file) {
console.log(file.messages);
});
Both tools offer powerful Markdown linting capabilities, but they cater to different use cases. markdownlint provides a more comprehensive set of rules out-of-the-box and better editor integration, making it suitable for quick setup and general use. remark-lint, on the other hand, offers greater flexibility and extensibility, making it ideal for projects with specific linting requirements or those looking to build custom rules.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
remark plugins to check (lint) markdown code style.
Contents
- What is this?
- When should I use this?
- Presets
- Rules
- Configure
- Ignore warnings
- Examples
- Integrations
- Syntax
- Compatibility
- Security
- Contribute
- License
What is this?

You can use this to check markdown.
Say we have a markdown file doc/example.md that contains:
1) Hello, _Jupiter_ and *Neptune*!
Then assuming we installed dependencies and run:
npx remark doc/ --use remark-preset-lint-consistent --use remark-preset-lint-recommended
We would get a report like this:
doc/example.md
1:2 warning Unexpected ordered list marker `)`, expected `.` ordered-list-marker-style remark-lint
1:25-1:34 warning Unexpected emphasis marker `*`, expected `_` emphasis-marker remark-lint
[cause]:
1:11-1:20 info Emphasis marker style `'_'` first defined for `'consistent'` here emphasis-marker remark-lint
â 2 warnings
This GitHub repository is a monorepo that contains ±70 plugins (each a rule that checks one specific thing) and 3 presets (combinations of rules configured to check for certain styles).
These packages are build on unified (remark). unified is a project that inspects and transforms content with abstract syntax trees (ASTs). remark adds support for markdown to unified. mdast is the markdown AST that remark uses. These lint rules inspect mdast.
When should I use this?
This project is useful when developers or technical writers are authoring documentation in markdown and you want to ensure that the markdown is consistent, free of bugs, and works well across different markdown parsers.
These packages are quite good at checking markdown. They especially shine when combined with other remark plugins and at letting you make your own rules.
Presets
Presets are combinations of rules configured to check for certain styles. The following presets only contain lint rules but you can make your own that include any remark plugins or other presets. The presets that are maintained here:
remark-preset-lint-consistentâ rules that enforce consistencyremark-preset-lint-markdown-style-guideâ rules that enforce the markdown style guideremark-preset-lint-recommendedâ rules that prevent mistakes or stuff that fails across vendors.
Rules
The rules that are maintained here:
remark-lint-blockquote-indentationâ check whitespace after block quote markersremark-lint-checkbox-character-styleâ check list item checkbox charactersremark-lint-checkbox-content-indentâ warn when too much whitespace follows list item checkboxesremark-lint-code-block-styleâ warn when code blocks do not adhere to a given styleremark-lint-correct-media-syntaxâ check for accidental bracket and paren mixup for images and linksremark-lint-definition-caseâ warn when definition labels are not lowercaseremark-lint-definition-sortâ check definition orderremark-lint-definition-spacingâ warn when consecutive whitespace is used in a definitionremark-lint-directive-attribute-sortâ check directive attribute orderremark-lint-directive-collapsed-attributeâ check that collapsed attributes are used in directivesremark-lint-directive-quote-styleâ check quotes of directive attributesremark-lint-directive-shortcut-attributeâ check that shortcut attributes are used in directivesremark-lint-directive-unique-attribute-nameâ check that attribute names are uniqueremark-lint-emphasis-markerâ warn when emphasis markers violate the given styleremark-lint-fenced-code-flagâ warn when fenced code blocks occur without language flagremark-lint-fenced-code-markerâ warn when fenced code markers violate the given styleremark-lint-file-extensionâ warn when the fileâs extension violates the given styleremark-lint-final-definitionâ warn when definitions are not placed at the end of the fileremark-lint-final-newlineâ warn when a newline at the end of a file is missingremark-lint-first-heading-levelâ warn when the first heading has a level other than a specified valueremark-lint-hard-break-spacesâ warn when too many spaces are used to create a hard breakremark-lint-heading-incrementâ warn when headings increment with more than 1 level at a timeremark-lint-heading-styleâ warn when heading style violates the given styleremark-lint-linebreak-styleâ warn when linebreaks violate a given or detected styleremark-lint-link-title-styleâ warn when link and definition titles occur with incorrect quotesremark-lint-list-item-bullet-indentâ warn when list item bullets are indentedremark-lint-list-item-content-indentâ warn when the content of a list item has mixed indentationremark-lint-list-item-indentâ check the spacing between list item bullets and contentremark-lint-list-item-spacingâ warn when list looseness is incorrectremark-lint-maximum-heading-lengthâ warn when headings are too longremark-lint-maximum-line-lengthâ warn when lines are too longremark-lint-mdx-jsx-attribute-sortâ check mdx jsx attribute orderremark-lint-mdx-jsx-no-void-childrenâ check mdx jsx quotesremark-lint-mdx-jsx-quote-styleâ check mdx jsx quotesremark-lint-mdx-jsx-self-closeâ check that self-closing tags are used when possibleremark-lint-mdx-jsx-shorthand-attributeâ check that shorthand attributes are used in MDX JSXremark-lint-mdx-jsx-unique-attribute-nameâ check that mdx jsx attributes are uniqueremark-lint-media-styleâ check whether references or resources are usedremark-lint-no-blockquote-without-markerâ warn when block quotes have blank lines without markersremark-lint-no-consecutive-blank-linesâ warn for too many consecutive blank linesremark-lint-no-duplicate-defined-urlsâ warn on definitions that define the same urlsremark-lint-no-duplicate-definitionsâ warn on duplicate definitionsremark-lint-no-duplicate-headingsâ warn on duplicate headingsremark-lint-no-duplicate-headings-in-sectionâ warn on duplicate headings in a sectionremark-lint-no-emphasis-as-headingâ warn when emphasis or importance is used instead of a headingremark-lint-no-empty-urlâ warn on empty URLs in links and imagesremark-lint-no-file-name-articlesâ warn when file name start with an articleremark-lint-no-file-name-consecutive-dashesâ warn when file names contain consecutive dashesremark-lint-no-file-name-irregular-charactersâ warn when file names contain irregular charactersremark-lint-no-file-name-mixed-caseâ warn when file names use mixed caseremark-lint-no-file-name-outer-dashesâ warn when file names contain initial or final dashesremark-lint-no-heading-content-indentâ warn when heading content is indentedremark-lint-no-heading-indentâ warn when headings are indentedremark-lint-no-heading-like-paragraphâ for too many hashes (h7+ âheadingsâ)remark-lint-no-heading-punctuationâ warn when headings end in illegal charactersremark-lint-no-hidden-table-cellâ check superfluous table cellsremark-lint-no-htmlâ warn when HTML nodes are usedremark-lint-no-literal-urlsâ warn when URLs without angle brackets are usedremark-lint-no-missing-blank-linesâ warn when missing blank linesremark-lint-no-multiple-toplevel-headingsâ warn when multiple top level headings are usedremark-lint-no-paragraph-content-indentâ warn when the content in paragraphs are indentedremark-lint-no-reference-like-urlâ warn when URLs are also defined identifiersremark-lint-no-shell-dollarsâ warn when shell code is prefixed by dollarsremark-lint-no-shortcut-reference-imageâ warn when shortcut reference images are usedremark-lint-no-shortcut-reference-linkâ warn when shortcut reference links are usedremark-lint-no-table-indentationâ warn when tables are indentedremark-lint-no-tabsâ warn when hard tabs are used instead of spacesremark-lint-no-undefined-referencesâ warn when references to undefined definitions are foundremark-lint-no-unneeded-full-reference-imageâ check that full reference images can be collapsedremark-lint-no-unneeded-full-reference-linkâ check that full reference links can be collapsedremark-lint-no-unused-definitionsâ warn when unused definitions are foundremark-lint-ordered-list-marker-styleâ warn when the markers of ordered lists violate a given styleremark-lint-ordered-list-marker-valueâ check the marker value of ordered listsremark-lint-rule-styleâ warn when horizontal rules violate a given styleremark-lint-strikethrough-markerâ warn when strikethrough markers violate the given styleremark-lint-strong-markerâ warn when importance (strong) markers violate the given styleremark-lint-table-cell-paddingâ warn when table cells are incorrectly paddedremark-lint-table-pipe-alignmentâ warn when table pipes are not alignedremark-lint-table-pipesâ warn when table rows are not fenced with pipesremark-lint-unordered-list-marker-styleâ warn when markers of unordered lists violate a given style
You can make and share your own rules, which can be used just like the rules maintained here. The following rules are maintained by the community:
remark-lint-alphabetize-listsâ ensure list items are in alphabetical orderremark-lint-appropriate-headingâ check that the top level heading matches the directory nameremark-lint-are-links-validâ check if your links are reachable and/or uniqueremark-lint-blank-lines-1-0-2â ensure a specific number of lines between blocksremark-lint-books-linksâ ensure links in lists of books follow a standard formatremark-lint-check-tocâ ensure TOC is correctremark-lint-codeâ lint fenced code blocks by corresponding language tags, currently supporting ESLintremark-lint-code-block-split-listâ ensure code block inside list doesn't split the listremark-lint-double-linkâ ensure the same URL is not linked multiple times.remark-lint-emoji-limitâ enforce a limit of emoji per paragraphremark-lint-fenced-code-flag-caseâ warn when fenced code blocks have improperly cased language flagsremark-lint-frontmatter-schemaâ validate YAML frontmatter against a JSON schemaremark-lint-heading-capitalizationâ ensure headings capitalization is correctremark-lint-heading-lengthâ ensure headings have the appropriate lengthremark-lint-heading-whitespaceâ ensure heading parsing is not broken by weird whitespaceremark-lint-heading-word-lengthâ warn when headings have too many or too few words with unicode supportremark-lint-list-item-styleâ warn when list items violate a given capitalization or punctuation styleremark-lint-match-punctuationâ ensures punctuations are used in pairs if necessary.remark-lint-mdash-styleâ ensure em-dash (â) style follows a standard formatremark-lint-no-chinese-punctuation-in-numberâ ensures that Chinese punctuationâs not used in numbersremark-lint-no-dead-urlsâ check that external links are aliveremark-lint-no-empty-sectionsâ ensure every heading is followed by content (forming a section)remark-lint-no-long-codeâ ensures that each line in code block won't be too long.remark-lint-no-repeat-punctuationâ ensures punctuation is not repeatedremark-lint-no-url-trailing-slashâ ensure that thehrefof links has no trailing slashremark-lint-spaces-around-numberâ ensures there are spaces around number and Chinese.remark-lint-spaces-around-wordâ ensures there are spaces around English word and Chinese.remark-lint-write-goodâ wrapper forwrite-good
For help creating your own rule, itâs suggested to look at existing rules and to follow this tutorial.
Configure
All rules can be configured in one standard way:
import {remark} from 'remark'
import remarkLintFinalNewline from 'remark-lint-final-newline'
import remarkLintMaximumLineLength from 'remark-lint-maximum-line-length'
import remarkLintUnorderedListMarkerStyle from 'remark-lint-unordered-list-marker-style'
remark()
// Pass `false` to turn a rule off â the code no longer runs:
.use(remarkLintFinalNewline, false)
// Pass `true` to turn a rule on again:
.use(remarkLintFinalNewline, true)
// You can also configure whether messages by the rule should be ignored,
// are seen as code style warnings (default), or are seen as exceptions.
// Ignore messages with `'off'` or `0` as the first value of an array:
.use(remarkLintFinalNewline, ['off'])
.use(remarkLintFinalNewline, [0])
// Use `'warn'`, `'on'`, or `1` to treat messages as code style warnings:
.use(remarkLintFinalNewline, ['warn'])
.use(remarkLintFinalNewline, ['on'])
.use(remarkLintFinalNewline, [1])
// Use `'error'` or `2` to treat messages as exceptions:
.use(remarkLintFinalNewline, ['error'])
.use(remarkLintFinalNewline, [2])
// Some rules accept options, and what they exactly accept is different for
// each rule (sometimes a string, a number, or an object).
// The following rule accepts a string:
.use(remarkLintUnorderedListMarkerStyle, '*')
.use(remarkLintUnorderedListMarkerStyle, ['on', '*'])
.use(remarkLintUnorderedListMarkerStyle, [1, '*'])
// The following rule accepts a number:
.use(remarkLintMaximumLineLength, 72)
.use(remarkLintMaximumLineLength, ['on', 72])
.use(remarkLintMaximumLineLength, [1, 72])
See use() in unifieds readme for more info on how to use
plugins.
ð§âð« Info: messages in
remark-lintare warnings instead of errors. Other linters (such as ESLint) almost always use errors. Why? Those tools only check code style. They donât generate, transform, and format code, which is what remark and unified focus on, too. Errors in unified mean the same as an exception in your JavaScript code: a crash. Thatâs why we use warnings instead, because we continue checking more markdown and continue running more plugins.
Ignore warnings
You can use HTML comments to hide or show warnings from within markdown.
Turn off all remark lint messages with <!--lint disable--> and turn them on
again with <!--lint enable-->:
<!--lint disable-->
[Naiad]: https://naiad.neptune
[Thalassa]: https://thalassa.neptune
<!--lint enable-->
You can toggle specific rules by using their names without remark-lint-:
<!--lint disable no-unused-definitions definition-case-->
[Naiad]: https://naiad.neptune
[Thalassa]: https://thalassa.neptune
<!--lint enable no-unused-definitions definition-case-->
You can ignore a message in the next block with <!--lint ignore-->:
<!--lint ignore-->
[Naiad]: https://naiad.neptune
ignore also accepts a list of rules:
<!--lint ignore no-unused-definitions definition-case-->
[Naiad]: https://naiad.neptune
ð Note: youâll typically need blank lines between HTML comments and other constructs. More info is available at the package that handles comments,
remark-message-control.
ð¡ Tip: MDX comments are supported when
remark-mdxis used:{/* lint ignore no-unused-definitions definition-case */}
Examples
Example: check markdown on the API
The following example checks that markdown code style is consistent and follows some best practices. It also reconfigures a rule. First install dependencies:
npm install vfile-reporter remark remark-preset-lint-consistent remark-preset-lint-recommended remark-lint-list-item-indent --save-dev
Then create a module example.js that contains:
import {remark} from 'remark'
import remarkLintListItemIndent from 'remark-lint-list-item-indent'
import remarkPresetLintConsistent from 'remark-preset-lint-consistent'
import remarkPresetLintRecommended from 'remark-preset-lint-recommended'
import {reporter} from 'vfile-reporter'
const file = await remark()
// Check that markdown is consistent.
.use(remarkPresetLintConsistent)
// Few recommended rules.
.use(remarkPresetLintRecommended)
// `remark-lint-list-item-indent` is configured with `one` in the
// recommended preset, but if weâd prefer something else, it can be
// reconfigured:
.use(remarkLintListItemIndent, 'tab')
.process('1) Hello, _Jupiter_ and *Neptune*!')
console.error(reporter(file))
Running that with node example.js yields:
1:2 warning Unexpected ordered list marker `)`, expected `.` ordered-list-marker-style remark-lint
1:4 warning Unexpected `1` space between list item marker and content, expected `2` spaces, add `1` space list-item-indent remark-lint
1:25-1:34 warning Unexpected emphasis marker `*`, expected `_` emphasis-marker remark-lint
[cause]:
1:11-1:20 info Emphasis marker style `'_'` first defined for `'consistent'` here emphasis-marker remark-lint
1:35 warning Unexpected missing final newline character, expected line feed (`\n`) at end of file final-newline remark-lint
â 4 warnings
Example: check and format markdown on the API
remark lint rules check markdown.
remark-stringify
(used in remark) formats markdown.
When you configure lint rules and use remark to format markdown, you must
manually synchronize their configuration:
import {remark} from 'remark'
import remarkLintEmphasisMarker from 'remark-lint-emphasis-marker'
import remarkLintStrongMarker from 'remark-lint-strong-marker'
import {reporter} from 'vfile-reporter'
const file = await remark()
.use(remarkLintEmphasisMarker, '*')
.use(remarkLintStrongMarker, '*')
.use({
settings: {emphasis: '*', strong: '*'} // `remark-stringify` settings.
})
.process('_Hello_, __world__!')
console.error(reporter(file))
console.log(String(file))
Yields:
1:1-1:8 warning Emphasis should use `*` as a marker emphasis-marker remark-lint
1:10-1:19 warning Strong should use `*` as a marker strong-marker remark-lint
â 2 warnings
*Hello*, **world**!
Observe that the lint rules check the input and afterwards remark formats using asterisks. If that output was given the the processor, the lint rules would be satisfied.
Example: check markdown on the CLI
This example checks markdown with remark-cli.
It assumes youâre in a Node.js package.
First install dependencies:
npm install remark-cli remark-preset-lint-consistent remark-preset-lint-recommended remark-lint-list-item-indent --save-dev
Then add an npm script to your package.json:
/* ⦠*/
"scripts": {
/* ⦠*/
"check": "remark . --quiet --frail",
/* ⦠*/
},
/* ⦠*/
ð¡ Tip: add ESLint and such in the
checkscript too.
Observe that the above change adds a check script, which can be run with
npm run check.
It runs remark on all markdown files (.), shows only warnings and errors
(--quiet), and exits as failed on warnings (--frail).
Run ./node_modules/.bin/remark --help for more info on the CLI.
Now add a remarkConfig to your package.json to configure remark:
/* ⦠*/
"remarkConfig": {
"plugins": [
"remark-preset-lint-consistent", // Check that markdown is consistent.
"remark-preset-lint-recommended", // Few recommended rules.
// `remark-lint-list-item-indent` is configured with `one` in the
// recommended preset, but if weâd prefer something else, it can be
// reconfigured:
[
"remark-lint-list-item-indent",
"tab"
]
]
},
/* ⦠*/
ð Note: you must remove the comments in the above examples when copy/pasting them, as comments are not supported in
package.jsonfiles.
Finally run the npm script to check markdown files in your project:
npm run check
Example: check and format markdown on the CLI
remark lint rules check markdown. The CLI can format markdown. You can combine these features but have to manually synchronize their configuration. Please first follow the previous example (checking markdown on the CLI) and then change the npm script:
/* ⦠*/
"scripts": {
/* ⦠*/
"format": "remark . --frail --output --quiet",
/* ⦠*/
},
/* ⦠*/
The script is now called format to reflect what it does.
It now includes an --output flag, which means it will overwrite existing files
with changes.
Update remarkConfig:
/* ⦠*/
"remarkConfig": {
"settings": {
"emphasis": "*",
"strong": "*"
},
"plugins": [
"remark-preset-lint-consistent",
"remark-preset-lint-recommended",
["remark-lint-list-item-indent", "tab"]
["remark-lint-emphasis-marker", "*"],
["remark-lint-strong-marker", "*"]
]
},
/* ⦠*/
This now includes settings, which configures
remark-stringify, and explicitly prefers asterisks
for emphasis and strong.
Install the new dependencies:
npm install remark-lint-emphasis-marker remark-lint-strong-marker --save-dev
Finally run the npm script to format markdown files in your project:
npm run format
ð Note: running
npm run formatnow checks and formats your files. The first time you run it, assuming you have underscores for emphasis and strong, it would first warn and then format. The second time you run it, no warnings should appear.
Integrations
vscode-remark-lint(VS Code) â useremark-lintfrom Visual Studio CodeSublimeLinter-contrib-remark-lint(Sublime) â useremark-lintfrom Sublime Textale(Vim) â useremark-lintfrom Vimjest-runner-remark(Jest) â use remark with Jest
Syntax
Markdown is parsed by remark-parse
(included in remark)
according to CommonMark.
You can combine it with other plugins to add syntax extensions.
Notable examples that deeply integrate with it are
remark-gfm,
remark-mdx,
remark-frontmatter,
remark-math, and
remark-directive.
Compatibility
Projects maintained by the unified collective are compatible with maintained versions of Node.js.
When we cut a new major release, we drop support for unmaintained versions of
Node.
This means we try to keep the current release line, remark-lint@9, compatible
with Node.js 16.
Security
Use of remark-lint does not change the tree so there are no openings for
cross-site scripting (XSS) attacks.
Messages from linting rules may be hidden from user content though, causing
builds to fail or pass.
Contribute
See contributing.md
in remarkjs/.github
for ways to get started.
See support.md for ways to get help.
This project has a code of conduct. By interacting with this repository, organization, or community you agree to abide by its terms.
License
MIT © Titus Wormer
Top Related Projects
A mighty CSS linter that helps you avoid errors and enforce conventions.
Find and fix problems in your JavaScript code.
Prettier is an opinionated code formatter.
textlint is the pluggable linter for natural language text.
A Node.js style checker and lint tool for Markdown/CommonMark files.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot