[GH-ISSUE #1327] Support rule option names in camelCase #659

Open
opened 2026-03-03 01:28:50 +03:00 by kerem · 1 comment
Owner

Originally created by @regseb on GitHub (Aug 13, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1327

Description

Option names are in snake_case (e.g. siblings_only for the no-duplicate-heading rule). camelCase names should also be supported (e.g. siblingsOnly).

Motivations

Originally created by @regseb on GitHub (Aug 13, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1327 ## Description Option names are in **snake_case** (e.g. `siblings_only` for the [`no-duplicate-heading`](https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md024.md#md024---multiple-headings-with-the-same-content) rule). **camelCase** names should also be supported (e.g. `siblingsOnly`). ## Motivations - Other linters are in camelCase. Here are some examples: - ESLint: `skipStrings` for [`no-irregular-whitespace`](https://eslint.org/docs/latest/rules/no-irregular-whitespace#skipstrings)` - Stylelint: `ignoreProperties` for [`property-no-unknown`](https://stylelint.io/user-guide/rules/property-no-unknown/#ignoreproperties-regex-regex-string) - Markuplint: `allowAttrs` for [`invalid-attr`](https://markuplint.dev/docs/rules/invalid-attr#setting-allow-attrs-option) - npm-package-json-lint: `requireCapitalFirstLetter` for [`description-format`](https://npmpackagejsonlint.org/docs/rules/format/description-format/#example-npmpackagejsonlintrc-configuration-with-only-requirecapitalfirstletter) - [My markdownlint configuration](https://github.com/regseb/gout/blob/v0.12.1/.metalint/markdownlint.config.js#L35-L36) is a JavaScript file that I check with ESLint and the [`camelcase`](https://eslint.org/docs/latest/rules/camelcase) rule. ESLint returns errors because the properties are in snake_case.
Author
Owner

@DavidAnson commented on GitHub (Aug 13, 2024):

This is a holdover from the original Ruby implementation. It's reasonable to do as you suggest, but I'd rather not code it into every rule or document/test/sample both forms. I'll think about how/when this might be least disruptive.

<!-- gh-comment-id:2286627547 --> @DavidAnson commented on GitHub (Aug 13, 2024): This is a holdover from the original Ruby implementation. It's reasonable to do as you suggest, but I'd rather not code it into every rule or document/test/sample both forms. I'll think about how/when this might be least disruptive.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/markdownlint#659
No description provided.