Open danbeam opened 1 month ago
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.
(Or invoke markdownlint-cli2
and tell it to apply fixes for you.)
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).
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)?
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
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 inlib/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:
which is fairly icky in that it's looking at the internals of the package 😅 .