Support for nested config files

[nschonni]

Maybe this I've just been setting it up wrong, but I don't think this currently works (or maybe it's a CLI/VS Code issue). Similar to ESLint, sometimes subfolders need a separate set of rules from the root configuration.

• .markdownlint.json
• docs
  • new docs
  • old docs
    • .markdownlint.json (to turn off some rules)

[DavidAnson]

The VS Code extension chooses the “nearest” version of .markdownlint.json. The CLI uses a single version, either what you specify as an argument or from the current directory. The Node package uses whatever you pass in the config object.

Because it’s configured once and scripted, my suggestion is to make multiple passes with the CLI, ignoring directories and passing different configurations as needed to treat each set of files like you want.

Or open an issue on the CLI to match the VS Code behavior. This isn’t the first time the question has come up.

[DavidAnson]

To be clear, I do not think this is the responsibility of the Node package – it just does what you tell it and is there to be used by other tools for richer scenarios like this one.

[nschonni]

This isn’t the first time the question has come up.

I took a quick search first, but didn't find anything 😊

I'm finding this come up on the MicrosoftDocs repos, because they sometimes have "legacy" docs in nested folders (or just weird subsections) they don't really want touched. I'm trying to figure out how a plain markdownlint "**/*.md" and VS Code editing experience should work in your view.
EX: Should the nested configs override a root config, or should they merge/extend? I can see both ways can be preferable to different users.

[DavidAnson]

Sorry, I didn’t mean to suggest you didn’t look, just that you’re not the only one thinking about this. :) For example: igorshubovych/markdownlint-cli#53

For the scenario you describe above, I might explore using extends first because that lets you exclude unwanted rules in just one place. DRY, but for configuration.

[DavidAnson]

Closing this issue as it does not seem to be applicable to the library and is tracked in the CLI with the issue above.