[GH-ISSUE #39] Add rule to enforce letter case of project names [WAS: How to add custom rules?] #31

New issue

Closed

opened 2026-03-03 01:23:10 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 01:23:10 +03:00

Owner

Originally created by @bebraw on GitHub (Dec 11, 2016).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/39

Hi,

I checked the docs/source but I didn't see any obvious extension mechanism (apart from forking). Do you have some preferred way on how to handle custom rules? I can see the rule mechanism itself is quite simple. If it was possible to inject new ones through the API somehow (match through npm/Node), I could likely do what I want (I need to verify certain word is lowercase always).

Originally created by @bebraw on GitHub (Dec 11, 2016). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/39 Hi, I checked the docs/source but I didn't see any obvious extension mechanism (apart from forking). Do you have some preferred way on how to handle custom rules? I can see the rule mechanism itself is quite simple. If it was possible to inject new ones through the API somehow (match through npm/Node), I could likely do what I want (I need to verify certain word is lowercase always).

kerem

2026-03-03 01:23:10 +03:00

closed this issue
added the
fixed in next

new rule
labels

kerem commented

2026-03-03 01:23:11 +03:00

Author

Owner

@DavidAnson commented on GitHub (Dec 11, 2016):

As you note, there is no public extension mechanism right now. Rules are already independent, so this is something I've considered - but it hasn't come up. I have some concerns about presenting a friendly API that versions well and I also haven't decided how I think rule names should integrate or migrate.

None of this is insurmountable, this just hasn't been a priority so far.

Regarding your specific desire, could you please describe it in a bit more detail? I wonder if there's a general-purpose rule I might add that would address your needs (and defer extensibility a bit longer).

@DavidAnson commented on GitHub (Dec 11, 2016): As you note, there is no public extension mechanism right now. Rules are already independent, so this is something I've considered - but it hasn't come up. I have some concerns about presenting a friendly API that versions well and I also haven't decided how I think rule names should integrate or migrate. None of this is insurmountable, this just hasn't been a priority so far. Regarding your specific desire, could you please describe it in a bit more detail? I wonder if there's a general-purpose rule I might add that would address your needs (and defer extensibility a bit longer).

kerem commented

2026-03-03 01:23:11 +03:00

Author

Owner

@bebraw commented on GitHub (Dec 12, 2016):

@DavidAnson My first use case is simple. I need to validate that people are writing webpack as webpack at webpack.js.org. It's a trivial check, but you have to start somewhere.

Basically I want to push as much work to CI as possible (faster reviews, less work).

@bebraw commented on GitHub (Dec 12, 2016): @DavidAnson My first use case is simple. I need to validate that people are writing webpack as webpack at [webpack.js.org](https://github.com/webpack/webpack.js.org). It's a trivial check, but you have to start somewhere. Basically I want to push as much work to CI as possible (faster reviews, less work).

kerem commented

2026-03-03 01:23:11 +03:00

Author

Owner

@DavidAnson commented on GitHub (Dec 13, 2016):

This seems like a rule that might be fairly broadly useful: ensure that certain names are cased in a standard manner. I have an idea how I could add a rule for this - I'll look into it shortly.

Thanks for the idea!

@DavidAnson commented on GitHub (Dec 13, 2016): This seems like a rule that might be fairly broadly useful: ensure that certain names are cased in a standard manner. I have an idea how I could add a rule for this - I'll look into it shortly. Thanks for the idea!

kerem referenced this issue

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

[GH-ISSUE #31] Ignore indenting within code blocks #1871