starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-25 01:05:55 +03:00

[GH-ISSUE #254] Specify per-rule severity (warning vs. error) #2067

New issue

Closed

opened 2026-03-07 20:04:13 +03:00 by kerem · 6 comments

kerem commented

2026-03-07 20:04:13 +03:00

Owner

Originally created by @t-rad679 on GitHub (Feb 13, 2020).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/254

Hello!

I can't seem to find a way to specify severity for rules, or even the entire config as a whole. I'd like to make it so only certain rules produce a non-zero exit code if they fail. Is there a way to do this presently, and, if not, can we add one?

Originally created by @t-rad679 on GitHub (Feb 13, 2020). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/254 Hello! I can't seem to find a way to specify severity for rules, or even the entire config as a whole. I'd like to make it so only certain rules produce a non-zero exit code if they fail. Is there a way to do this presently, and, if not, can we add one?

kerem

2026-03-07 20:04:13 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (Feb 13, 2020):

This is an issue for the CLI repository: https://github.com/igorshubovych/markdownlint-cli

Unfortunately, I cannot transfer it, so please open this there instead.

There is not currently a notion of “warnings“ in the tool. General best practice around development tools is to set “warnings as errors“, so I’m not sure this is something I want to add. What is the scenario?

@DavidAnson commented on GitHub (Feb 13, 2020): This is an issue for the CLI repository: https://github.com/igorshubovych/markdownlint-cli Unfortunately, I cannot transfer it, so please open this there instead. There is not currently a notion of “warnings“ in the tool. General best practice around development tools is to set “warnings as errors“, so I’m not sure this is something I want to add. What is the scenario?

kerem commented

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

Author

Owner

@t-rad679 commented on GitHub (Feb 13, 2020):

I have one rule for markdownlint I'd like for engineers to be aware of, but I don't want our pre-merge lint checks to fail and prevent submission...Specifically the inline html rule. The other rules I'd like to fail (return non-zero exit status). In general, I think this is a pretty useful feature that most linters have and I was just a little surprised it didn't exist here.

I could see how providing this option for the ruleset as a whole could be solved in the CLI, but it doesn't seem optimal to solve it per-rule there. You could do it with command line options, but I feel like it would be cleaner to include a configuration option for it on every rule, and possibly the ability to set a global default that can be overridden per rule. I can also file a ticket with the CLI project, but that does seem less practical to me.

@t-rad679 commented on GitHub (Feb 13, 2020): I have one rule for markdownlint I'd like for engineers to be aware of, but I don't want our pre-merge lint checks to fail and prevent submission...Specifically the inline html rule. The other rules I'd like to fail (return non-zero exit status). In general, I think this is a pretty useful feature that most linters have and I was just a little surprised it didn't exist here. I could see how providing this option for the ruleset as a whole could be solved in the CLI, but it doesn't seem optimal to solve it per-rule there. You could do it with command line options, but I feel like it would be cleaner to include a configuration option for it on every rule, and possibly the ability to set a global default that can be overridden per rule. I can also file a ticket with the CLI project, but that does seem less practical to me.

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (Feb 14, 2020):

Could you run two passes? The first has the rules you care to enforce and will fail the build. The second has rules you expect people to ignore and doesn’t fail the build.

@DavidAnson commented on GitHub (Feb 14, 2020): Could you run two passes? The first has the rules you care to enforce and will fail the build. The second has rules you expect people to ignore and doesn’t fail the build.

kerem commented

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

Author

Owner

@t-rad679 commented on GitHub (Feb 14, 2020):

That works. It seems kind of like a hack, but I'm sure you have a lot going on and need to prioritize. I get that some less important requests, more time-consuming requests, or requests that have workarounds, might not realistically be gotten to.

I do think the feature this issue is requesting is pretty standard and useful for linting tools, though. With the exception of Prettier (which is very opinionated and ONLY performs fixes; it does not just do checks under any circumstances. We mostly use it for JSON config files.), all of our other linters (ESLint, Stylelint, Checkstyle, the Eclipse formatter used with Spotless, and remark.js) have a concept of warn vs error for each rule.

Thank you for your help!

@t-rad679 commented on GitHub (Feb 14, 2020): That works. It seems kind of like a hack, but I'm sure you have a lot going on and need to prioritize. I get that some less important requests, more time-consuming requests, or requests that have workarounds, might not realistically be gotten to. I do think the feature this issue is requesting is pretty standard and useful for linting tools, though. With the exception of Prettier (which is very opinionated and ONLY performs fixes; it does not just do checks under any circumstances. We mostly use it for JSON config files.), all of our other linters (ESLint, Stylelint, Checkstyle, the Eclipse formatter used with Spotless, and remark.js) have a concept of ```warn``` vs ```error``` for each rule. Thank you for your help!

kerem commented

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

Author

Owner

@lishaduck commented on GitHub (Feb 14, 2025):

I'd like to note that in some ecosystems, supporting this is anti-pattern: How disable comments make static analysis tools worse § Warnings. I think two passes makes a lot more sense than adding in support directly.

(The article is from Elm, while in Dart we have severities but pretty much always pass --fatal-infos so that they're pretty much just for the IDE)

@lishaduck commented on GitHub (Feb 14, 2025): I'd like to note that in some ecosystems, supporting this is anti-pattern: [How disable comments make static analysis tools worse § Warnings](https://jfmengels.net/disable-comments/#warnings). I think two passes makes a lot more sense than adding in support directly. (The article is from Elm, while in Dart we have severities but pretty much always pass `--fatal-infos` so that they're pretty much just for the IDE)

kerem commented

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

Author

Owner

@jarpoole commented on GitHub (Jun 29, 2025):

One argument for warnings (or as https://jfmengels.net/disable-comments/#distinguishing-between-temporarily-ignored-and-permanently-ignored mentions, a different dedicated feature) is incremental adoption. I am investigating enabling markdownlint on a large repo and requiring two passes is pretty clumsy.

@jarpoole commented on GitHub (Jun 29, 2025): One argument for warnings (or as https://jfmengels.net/disable-comments/#distinguishing-between-temporarily-ignored-and-permanently-ignored mentions, a different dedicated feature) is incremental adoption. I am investigating enabling markdownlint on a large repo and requiring two passes is pretty clumsy.