Coder Social home page Coder Social logo

remarkjs / remark-lint Goto Github PK

View Code? Open in Web Editor NEW
918.0 17.0 131.0 4.5 MB

plugins to check (lint) markdown code style

Home Page: https://remark.js.org

License: MIT License

JavaScript 100.00%
remark remark-lint markdown lint check style-linter style remark-plugin

remark-lint's Introduction

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

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 {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 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 `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.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 . --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 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 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

remark-lint's People

Contributors

alexandrtovmach avatar alexwayfer avatar benbalter avatar chalker avatar christianmurphy avatar coderaiser avatar greenkeeperio-bot avatar jablko avatar michaelmior avatar murderlon avatar nulltoken avatar pcgilday avatar pkuczynski avatar planeshifter avatar remcohaszing avatar rhysd avatar richardlitt avatar rwhogg avatar sisp avatar sobolevn avatar spl avatar strajk avatar trott avatar uzitech avatar vhf avatar wooorm avatar xunnamius avatar yash-nisar avatar yoshuawuyts avatar zcei avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

remark-lint's Issues

no-missing-blank-lines false positives

for lists using double indent

- list item
    - nested item with 4 space indent

the rule expects a blank line in between the two
I believe this is a false positive since the block nodes are nested, not adjacent when rendered as html

Add support for external rules

With this I could build standard-readme as a semantic rule checked by mdast-lint.

I think about smth like this:

{
  "standard-readme": true
}

or even with customization:

{
  "standard-readme": {
    "optional-blocks": ["badges", "reference"]
    "order": ["heading", "badge", "description"]
  }
}

Add a rule to detect broken internal links

By internal links I mean:

  • [see this file](another/file.md)
  • [see this header](#some-header)

I often avoid writing those because I know they will break sooner or later, but I would really like to use internal links.

If only I had a tool that notified me when either of those broke, that would be awesome ... :-)

Header links are a bit harder since they require you to specify the ID generation rule which is not standardized... but we could just start by copying GitHub's which works well for common headers of most implementations. See: https://github.com/************/test/blob/master/md.md#012-uppercase-underline_hyphen-spaces--othersend

On markdownlint: markdownlint/markdownlint#95

Output custom severity warnings

Is there a way to output custom severity ? At this moment only warnings are available as i can see.

  • along with defining custom rule you could also have a severity type when linter catches it.
  • could it be possible?
    This could be helpful for CI.

Thanks!

The `list-item-indent` rule is buggy when it comes to checkboxes

╭─soda  ~/Tests/remark-lint
╰─$ npm list -g --depth=0 remark remark-lint
/Users/soda/.nvm/versions/node/v4.2.6/lib
+-- [email protected]
`-- [email protected]

╭─soda  ~/Tests/remark-lint
╰─$ cat test.md
- [ ] Item 1
- [x] Item 2
- [ ] Item 3
╭─soda  ~/Tests/remark-lint
╰─$ cat .remarkrc
{
    "plugins": {
        "lint": {
            "reset": true,
            "list-item-indent": 'space'
        }
    },
    "settings": {
        "gfm": true
    }
}
╭─soda  ~/Tests/remark-lint
╰─$ remark test.md -u remark-lint -c .remarkrc
-   [ ] Item 1
-   [x] Item 2
-   [ ] Item 3
test.md
        1:7  warning  Incorrect list-item indent: add 2 spaces  list-item-indent
        2:7  warning  Incorrect list-item indent: add 2 spaces  list-item-indent
        3:7  warning  Incorrect list-item indent: add 2 spaces  list-item-indent

⚠ 3 warnings

Turn no-shell-dollars off by default

Philosophical like any defaults question but there goes... :-)

I think there would be too many false positives.

All checks seem to be turned on by default currently is that so?

Prevent markdown contents from being output before the warnings

Unless I'm missing something, when I run mdast -u mdast-lint README.md I get in the output the complete markdown document contents before any warnings are printed. What I would like to do is just print any warnings. If there are no errors, I would like to get nothing at all or just a line stating that no warnings are found. Is this possible currently?

Thanks

Extend table rules to alignment-row

All current table rows ignore the alignment row (| :---- | ----: | ------ | :-----: |), it’s pretty hard to detect, but should be done.

Multiple lines in table cells

There is no rule how to style table cells which have multiple line content. Is it possible to add a rule? All researched solutions use HTML ('br').

coala Integration

You state you'd be interested in further integration. I'm the founder of a little open source project that aims to provide user interaction for any code analysis. Currently we're writing wrappers for linters like yours and the cool thing is integrating a linter can take as short as five minutes (given that you know coala a bit.)

An example for an integration with indent (which actually generates results that allow coala to also fix the issues automatically if so desired by the user) is here: coala/coala@58ecf96#diff-4303149460ecafb6e4092292d03d667aR13

Would you be interested in writing mdast-lint integration for coala? That would provide you with a plugin to:

  • gedit
  • sublime
  • atom

(Though we haven't uploaded those anywhere yet but they're there.)

It also gives you a nice user interaction and features like JSON export and stuff like that, in case you miss those.

How to pass options to remark-lint on the CLI?

Is there a way to pass mdast-lint-specific options via the CLI? I know .mdastrc is the place for these, but it'd be convenient to be able to use my custom rules straight from the CLI without having to write a .mdastrc.

Blockquotes indentation produces error if no content

While using https://atom.io/packages/linter-markdown:

Started typing a block quote:

>

This error was produced:

TypeError: Cannot read property 'children' of undefined
  at toString (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-to-string/index.js:33:14)
  at check (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/blockquote-indentation.js:49:19)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/blockquote-indentation.js:97:25
  at one (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:96:22)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:83:29
  at forwards (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:24:13)
  at all (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:82:16)
  at one (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:100:20)
  at visit (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/node_modules/mdast-util-visit/index.js:106:5)
  at blockquoteIndentation (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/blockquote-indentation.js:73:5)
  at Of.plugin (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:89:13)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at done (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:82:17)
  at noMissingBlankLines (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/no-missing-blank-lines.js:74:5)
  at Of.plugin (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:89:13)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at done (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:82:17)
  at noConsecutiveBlankLines (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/no-consecutive-blank-lines.js:121:5)
  at Of.plugin (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:89:13)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at done (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:82:17)
  at noLiteralURLs (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/no-literal-urls.js:55:5)
  at Of.plugin (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:89:13)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at done (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:82:17)
  at noAutoLinkWithoutProtocol (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/rules/no-auto-link-without-protocol.js:77:5)
  at Of.plugin (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast-lint/lib/index.js:89:13)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:83:42)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:57:27)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:83:42)
  at Of.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:57:27)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at Of.Ware.run (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:88:3)
  at Processor.run (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/unified/index.js:149:23)
  at Ware.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/unified/index.js:30:21)
  at Ware.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at /Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:121:18
  at Ware.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:83:42)
  at Ware.<anonymous> (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/node_modules/wrap-fn/index.js:57:27)
  at next (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:85:20)
  at Ware.run (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/ware/lib/index.js:88:3)
  at Processor.process (/Users/leipert/.atom/packages/linter-markdown/node_modules/mdast/node_modules/unified/index.js:243:18)
  at module.exports._Class.lint (/Users/leipert/.atom/packages/linter-markdown/lib/linter.coffee:56:19)
  at _Class.module.exports._Class.lint (/Users/leipert/.atom/packages/linter-markdown/lib/linter.coffee:55:11)
  at _Class.__bind [as lint] (/Users/leipert/.atom/packages/linter-markdown/lib/linter.coffee:1:1)
  at LinterRegistry.triggerLinter.Promise.then._this.emitter.emit.linter (/Users/leipert/.atom/packages/linter/lib/linter-registry.coffee:55:22)
  at LinterRegistry.triggerLinter (/Users/leipert/.atom/packages/linter/lib/linter-registry.coffee:54:16)
  at /Users/leipert/.atom/packages/linter/lib/linter-registry.coffee:48:17
  at Array.map (native)
  at /Users/leipert/.atom/packages/linter/lib/linter-registry.coffee:46:27
  at process._tickCallback (node.js:367:9)

Update remark from 4 alpha to 4.2

It seems that the dependency for remark is 4.0.0-alpha, while the latest is 4.2.0.
Any chance to update to that and make a release such as 3.1.0?

Settings seems to not be taken into account

Given the following files

test.md

*emphasized* topic

```bash
$ cd /path/

$ source .env
```

validate.md.sh

#!/bin/bash
set -e

FILES=$(find . -name "*.md" -not -path "*/node_modules/*" -type f)

for f in $FILES
do
    cat $f | remark -u remark-lint --frail --no-stdout --quiet --file-path $f
done

exit $?

.remarkrc.js

module.exports = {
  "plugins": {
    "remark-lint": {
      "emphasis-marker": "_",
      "no-shell-dollars": false
    }
  },
  "settings": {
    "commonmark": true
  }
};

package.json

{
  "name": "repro-remark-lint",
  "version": "1.0.0",
  "license": "MIT",
  "private": true,
  "engines": {
    "node": "4.x"
  },
  "devDependencies": {
    "remark": "^4.2.0",
    "remark-lint": "^3.1.0"
  },
  "scripts": {
    "lint:md": "bash validate.md.sh"
  }
}

The following commands issue some wrong errors:

$ npm install
$ npm run lint:md

test.md
    3:1-7:4  warning  Do not use dollar signs before shell-commands  no-shell-dollars

‼ 1 warning

Where I was rather expecting an error related to the wrong emphasis marker.

It looks like the configuration may not be taken into account.

Fully support commonmark

If I set commonmark: true in mdast, does it affect the linter? So that some rules are turned off/on?

Furthermore I recognized, that nested blockquotes are not linted correctly:

screen shot 2015-08-04 at 10 47 25

Return an error status when there are lint errors

I would like to use the linter with a CI like TravisCI, so that when there are lint errors, it returns an error and the build fails. So I have in my package.json a script entry like "lint": "mdast -u mdast-lint README.md" and then I run npm run lint. Is that currently possible? I think currently it doesn't return an error, unless I'm missing something..

Thanks

Cannot disable no-literal-urls

Setting the no-literal-urls flag to false suppresses the warning, when running remark-lint, but if the output flag is set to true, all links are wrapped with < and > tags, regardless of the no-literal-urls flag.

This is especially troublesome when gfm is set to true, as GFM supports autolinking, and thus theoretically the parser shouldn't rewrite the links when outputting.

Example (with gfm: true and no-literal-urls: false):

Input:

Link to example.com.

Expected:

Link to example.com.

(Identical)

Actual:

Link to <example.com>.

Allow for Jekyll links

I'm trying to use this linter with a Jekyll project, but Jekyll's programmatic links aren't supported. I would love to have Jekyll's use of the Liquid templating system supported.

image

Add special rules for document types

  • readme: standard/standard#141 has a great list of useful “readme rules”;
  • history:
  • maybe validate the headings to a certain standard (\d\.\d\.\d \/ \d{4}-\d{2}-\d{2});
  • maybe require a commit reference at the end of a list-item?
  • \.\d — man section document (e.g., mdast.1.md):
  • Have a main heading in the form of \w+ \(\d\) -- .+
  • Have a synopsis heading (maybe validate its content?);
  • Have a description, bugs, and author heading;

...more?

Feature request: ability to specify the regex for `no-file-name-irregular-characters`

The current regular expression for the rule no-file-name-irregular-characters is /[^.a-zA-Z0-9-]/, which mandates that filenames only contain alphanumeric characters, hyphens, and/or periods.

Currently, the only option is to either opt-in or opt-out. It would be beneficial to be able to specify the allowed characters. For instance, some projects may find underscores acceptable, along with the current allowed characters.

Specifying a regular expression in the configuration file is possible, including in JSON. If the value is a string, a regular expression can be generated from that string.

Validate title quotes

[foo](http://example.com "Double")
[foo](http://example.com 'Single')
[foo](http://example.com (Single)) - only in commonmark

How to fix Markdown?

One thing that annoys me is my text editor sometimes inserts hard breaks in my paragraphs.

Is there an easy way to automatically get rid of the hard line breaks for paragraphs with this tool?

List errors question

In Atom with linter-markdown given the following list with sub-items which I assume is valid GFM markdown. (derived from syntax-tree/mdast#29 (comment))

-   aa
    -   ab
        -   ac
-   ba
    -   bb
        -   bc
-   ca
    -   cb
        -   cc

I see the following errors:

Error
Missing blank line before block node at line 2 col 5
Error
Missing blank line before block node at line 3 col 9
Error
List item should be loose, isn’t at line 3 col 15
Error
Missing blank line before block node at line 5 col 5
Error
Missing blank line before block node at line 6 col 9
Error
List item should be loose, isn’t at line 6 col 15
Error
Missing blank line before block node at line 8 col 5
Error
Missing blank line before block node at line 9 col 9

I'm curious as to why I'm receiving these errors. Is this a bug, or am I misunderstanding something here?

Thanks!

Bug with false positive for hard-break-spaces

I have a markdown file with the following markup:

-   A bullet with two trailing spaces  
    Next line obviously starting with two spaces.

The linter shows the warning: Use two spaces for hard line break but that is exactly what the example does.

From looking into a code the contents.slice(start, end) (https://github.com/wooorm/mdast-lint/blob/50f350b02f8d0859663c45a5760f0767e9195670/lib/rules/hard-break-spaces.js#L49) seems to contain not only the two trailing spaces and the newline but also the two leading spaces of the next line. Therefore the length is greater then 3 hence the warning.

Arguably I could remove the leading spaces but I think the rule should not trigger in this case.

Add gap support

I’m privately using mdast-lint in a workflow with other plug-ins, such as mdast-toc: a plug-in which generates content.

As outlined in the readme, those should be applied first. That’s because generated nodes of course do not have positional information. Thus, rules which only check a files contents, cannot white-list certain ranges.

However, by ignoring lines which are not available in the AST, those warnings can be hidden.

Allow external .remarkrc file to be used

Trying to get standard-readme going (again, as always). The remark-lint defaults are great, but I want something a bit more strict.

Do you have any ideas as to how to use one .remarkrc in a CLI tool for markdown files in directories that can't see that .remarkrc? I think some sort of alias might work, but I'm just wondering if you've thought of this before.

list-item-indent: incorrect warnings for bullets which are not incremented

If a ordered list of the following style is created:

1. One
1. Two
1. Three
1. Four
1. Five
1. Six
1. Seven
1. Eight
1. Nine
1. Ten

remark-lint complains for the last line:
Incorrect list-item indent:add 1 space ...

I assume the problem is that remark replaces 1. Ten with 10. Ten.

I don't think this is the intended behavior.

New rule: `no-reference-like-url`

<!-- Good -->
[this](http://example.com) and [that][]

[that]: https://example.com

<!-- Bad -->
[this](that) and [that][]

[that]: https://example.com

Validate checkboxes

If i remember correctly, GitHub is really weird about what is allowed for checkboxes, I think \[\n\] is a valid unchecked checkbox. But this should probably be warned about!

Same goes for [x] or [X].

remarkrc not overriding defaults

Upgraded to 2.3.0 and getting warnings about maximum-line-length in spite of it being set to false in the .remarkrc, shown below. Set this from false to 100 and I get two warnings from the same line that it exceeds 80 (default) and 100 (my setting).

{
  "plugins": {
    "lint": {
        "maximum-line-length": 100
    }
  },
  "settings": {
    "commonmark": true
  }
}

image

Remark Lint escapes underscores in emoji

Running remark lint with the default configuration escapes underscores in GitHub-style emoji, e.g., :heavy_check_mark:.

Turning on pedantic mode, replaces the underscores with the emphasis character, e.g., :heavy*check*mark:.

Steps to reproduce:

  1. Create a markdown file with :heavy_check_mark:
  2. remark example.md -u remark-lint --output

Expected

File contains :heavy_check_mark:

Actual

File contains :heavy\_check\_mark:

`Missing blank line before block node` in sub list items

With the following construct

* First level
  * Second level
  * Second level too
* Another first level

The linter reports Missing blank line before block node at line 2 ...

If changed to:

* First level

  * Second level
  * Second level too
* Another first level

the error goes away.

However I would assume the first case is valid as my markdown render adds an extra blank line between first and second level, which is not what I want.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.