[GH-ISSUE #23] Enhancement: Custom error messages #1866

New issue

Closed

opened 2026-03-07 20:02:14 +03:00 by kerem · 3 comments

kerem commented

2026-03-07 20:02:14 +03:00

Owner

Originally created by @originalfoo on GitHub (Jun 19, 2016).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/23

Rules

Currently rules have a static error message, it would be useful if they could generate context-sensitive errors, for example:

errors.push({
  lineNumber: whatever,
  error: `The '${headingText}' heading should be at level ${expectedLevel}`
});

Styles

An optional top-level error message that gets output upon the first error for a given batch of documents.

options.config._guidance = 'Please refer to the style guide for more information on the errors below: http://whatever.com/styleguide'

This would be particularly useful in CI builds of open source projects to help guide contributors to the style guide or templates, etc.

Originally created by @originalfoo on GitHub (Jun 19, 2016). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/23 ## Rules Currently rules have a static error message, it would be useful if they could generate context-sensitive errors, for example: ``` js errors.push({ lineNumber: whatever, error: `The '${headingText}' heading should be at level ${expectedLevel}` }); ``` ## Styles An optional top-level error message that gets output upon the first error for a given batch of documents. ``` js options.config._guidance = 'Please refer to the style guide for more information on the errors below: http://whatever.com/styleguide' ``` This would be particularly useful in CI builds of open source projects to help guide contributors to the style guide or templates, etc.

kerem

2026-03-07 20:02:14 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-07 20:02:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 21, 2016):

Makes total sense. Will think about this more and look into it soon! Much appreciated. :)

@DavidAnson commented on GitHub (Jun 21, 2016): Makes total sense. Will think about this more and look into it soon! Much appreciated. :)

kerem commented

2026-03-07 20:02:15 +03:00

Author

Owner

@originalfoo commented on GitHub (Jun 21, 2016):

On the subject of custom rule errors, it would be useful if configurable rules stated the config in their error message. For example, I just got these CI errors on some doc updates for eslint:

docs/rules/sort-imports.md: 164: MD004 Unordered list style
docs/rules/sort-imports.md: 37: MD007 Unordered list indentation

I had to search build scripts to work out what params had been sent to the linter, for example how many spaces should be used for list indentation? It would save time if errors looked like this:

docs/rules/sort-imports.md: 164: MD004 Use {asterisk} style for unordered lists
docs/rules/sort-imports.md: 37: MD007 Use {4} spaces when indenting lists

That will enable me, and others, to see at a glance what needs changing to fix an error.

@originalfoo commented on GitHub (Jun 21, 2016): On the subject of custom rule errors, it would be useful if configurable rules stated the config in their error message. For example, I just got these CI errors on some doc updates for eslint: ``` docs/rules/sort-imports.md: 164: MD004 Unordered list style docs/rules/sort-imports.md: 37: MD007 Unordered list indentation ``` I had to search build scripts to work out what params had been sent to the linter, for example how many spaces should be used for list indentation? It would save time if errors looked like this: ``` docs/rules/sort-imports.md: 164: MD004 Use {asterisk} style for unordered lists docs/rules/sort-imports.md: 37: MD007 Use {4} spaces when indenting lists ``` That will enable me, and others, to see at a glance what needs changing to fix an error.

kerem commented

2026-03-07 20:02:15 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 24, 2016):

This ended up being a bigger task than I expected, but I think it's a significant improvement, thanks for suggesting it!

PS - I did not implement a guidance message because it seems like configuration/process that will be handled differently by various projects (documentation, output message, code comment, etc.).

@DavidAnson commented on GitHub (Oct 24, 2016): This ended up being a bigger task than I expected, but I think it's a significant improvement, thanks for suggesting it! PS - I did not implement a guidance message because it seems like configuration/process that will be handled differently by various projects (documentation, output message, code comment, etc.).

kerem referenced this issue

2026-03-07 20:14:36 +03:00

[PR #1866] [MERGED] Bump webpack from 5.102.1 to 5.103.0 #3607