Export a list of available (and/or fixable) rules

[danbeam]

I'd like to apply all possible fixes for rules found in this library (use case: autofix bot) and would like to not have to handle the discovery myself.

A possible solution: publicly expose a list of all rules or the fixableRuleNames that are exported in lib/constants.js but more publicly (at least I haven't found a good way to otherwise get at this data).

I'm currently deriving a list of all rules via:

globby.sync('node_modules/markdownlint/doc/md*.md').map((file) => path.basename(file, '.md'))

which is fairly icky in that it's looking at the internals of the package 😅 .

[DavidAnson]

Sorry, I don't understand your scenario. What I would expect is to call the library to lint some sort of files and then look at the results of that operation. That provides the list of failing rules and those errors with fix information are fixable. If you want to make your life easier, pass that to the applyFixes helper and update the file accordingly. I'm not seeing why you need to enumerate the implemented rules or the fixable rules as that information doesn't seem necessary per the scenario above.

https://github.com/DavidAnson/markdownlint/blob/b2305efafb034b1f328845aec9928b5363ffd646/helpers/helpers.js#L922

[DavidAnson]

(Or invoke markdownlint-cli2 and tell it to apply fixes for you.)

[danbeam]

The script takes a --rule option and I'm feeding yargs all the choices: string[] so that yargs() does the validation and also shows them all in --help.

I might also eventually show aliases or resolve to a canonical format because right now it's possible to get into a funky state (e.g. --rule <alias> is invalid and alias: false in our .markdownlint.cjs + equivalent --rule md0## has no effect).

[danbeam]

Generally speaking though, is there not currently / do you not see the point of a rule discovery mechanism? At the simplest, just a list of all rules? Preferably with references to each of the rules' metadata.

Isn't your own doc making use of this type of list (IIRC you're using fixableRuleNames as a set and asking if that set .has() that rule name when generating your own doc .md files, eh)?

[DavidAnson]

It sounds like you are implementing another CLI? If so, I would be curious what about the existing ones is lacking?

But regarding rule metadata, everything you mention above (and more) is available in the JSON schema for configuration. This is intended to be a consumable artifact, so it is perfectly reasonable to reference and use it from the package.

https://github.com/DavidAnson/markdownlint/blob/main/schema/markdownlint-config-schema.json

[JulesGuesnon]

Hello,

I would like to re-open the issue if possible. The main reason I think the rules should be exported is for the eslint package.

For the context, I recently installed it, and there is a bug that makes it impossible to use it because it's not handling some new rules, and all the rules are listed again manually. I can enter in the details if necessary, but this package would benefit a lot from being able to import all the rules and generate the required data for eslint based on it. If you also have a look to a rule, there is some data in common: description and name.

[DavidAnson]

@JulesGuesnon, see above, please, this information is already available in an easily consumable form via the JSON schema.