/remark-lint

plugins to check (lint) markdown code style

Primary LanguageJavaScriptMIT LicenseMIT

remark-lint

Build Coverage Downloads Chat Sponsors Backers

remark plugins to check (lint) markdown code style.

Contents

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:1-1:35  warning  Marker style should be `.`               ordered-list-marker-style  remark-lint
        1:4  warning  Incorrect list-item indent: add 1 space  list-item-indent           remark-lint
  1:25-1:34  warning  Emphasis should use `_` as a marker      emphasis-marker            remark-lint

⚠ 3 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:

Rules

The rules that are maintained here:

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:

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-lint are 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-mdx is 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 {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkPresetLintConsistent from 'remark-preset-lint-consistent'
import remarkPresetLintRecommended from 'remark-preset-lint-recommended'
import remarkLintListItemIndent from 'remark-lint-list-item-indent'

main()

async function main() {
  const file = await remark()
    // Check that markdown is consistent.
    .use(remarkPresetLintConsistent)
    // Few recommended rules.
    .use(remarkPresetLintRecommended)
    // `remark-lint-list-item-indent` is configured with `tab-size` in the
    // recommended preset, but if we’d prefer something else, it can be
    // reconfigured:
    .use(remarkLintListItemIndent, 'space')
    .process('1) Hello, _Jupiter_ and *Neptune*!')

  console.error(reporter(file))
}

Running that with node example.js yields:

        1:1  warning  Missing newline character at end of file  final-newline              remark-lint
   1:1-1:35  warning  Marker style should be `.`                ordered-list-marker-style  remark-lint
  1:25-1:34  warning  Emphasis should use `_` as a marker       emphasis-marker            remark-lint

⚠ 3 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 {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkLintEmphasisMarker from 'remark-lint-emphasis-marker'
import remarkLintStrongMarker from 'remark-lint-strong-marker'

main()

async function main() {
  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 check script 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 `tab-size` in the
      // recommended preset, but if we’d prefer something else, it can be
      // reconfigured:
      [
        "remark-lint-list-item-indent",
        "space"
      ]
    ]
  },
  /* … */

👉 Note: you must remove the comments in the above examples when copy/pasting them, as comments are not supported in package.json files.

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 . --quiet --frail --output",
    /* … */
  },
  /* … */

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", "space"]
      ["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 format now 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

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 all maintained versions of Node.js. As of now, that is Node.js 12.20+, 14.14+, and 16.0+. Our projects sometimes work with older versions, but this is not guaranteed.

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