[GH-ISSUE #1139] Customizing plugins, other options with VSCode extension #2470

New issue

Closed

opened 2026-03-07 20:08:04 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 20:08:04 +03:00

Owner

Originally created by @heaths on GitHub (Feb 26, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1139

We have the same problem as #578 for the Azure SDK repos where we have both global (via include) and relative (via include_relative) refs. In my endeavor to be lint-clean (to spot actual issues), this creates a lot of noise. I don't want to disable MD0052 and MD0053 entirely because we may actually forget to create a link we intended to.

Is there a way and, if not (which it seems there is not), to configure plugins via configuration? Seems the only way is when calling this library's methods directly and not when, for example, using the VSCode extension. For example, could we provide a list of .js files to "hook" the linting process?

Or, if the problem of includes is common enough, what about config to just always include files (supporting a globbing pattern, perhaps, read at the beginning) to inline as if part of the markdown content?

I should be able to find some time to contribute if there's interest in either - or alternative - courses.

Originally created by @heaths on GitHub (Feb 26, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1139 We have the same problem as #578 for the Azure SDK repos where we have both global (via `include`) and relative (via `include_relative`) refs. In my endeavor to be lint-clean (to spot actual issues), this creates a lot of noise. I don't want to disable MD0052 and MD0053 entirely because we may actually forget to create a link we intended to. Is there a way and, if not (which it seems there is not), to configure plugins via configuration? Seems the only way is when calling this library's methods directly and not when, for example, using the VSCode extension. For example, could we provide a list of `.js` files to "hook" the linting process? Or, if the problem of includes is common enough, what about config to just always include files (supporting a globbing pattern, perhaps, read at the beginning) to inline as if part of the markdown content? I should be able to find some time to contribute if there's interest in either - or alternative - courses.

kerem

2026-03-07 20:08:04 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 20:08:05 +03:00

Author

Owner

@DavidAnson commented on GitHub (Feb 26, 2024):

Fundamentally, you are trying to use a Markdown linter on something that isn’t (yet) complete Markdown. Per my comment in the other issue, I think it’s better in the abstract to lint the final document.

Leaving that aside, what I think you are proposing is to create a markdown-it plugin that fills in the referenced content at parse time. It is possible to use such plugins with the VS Code extension, but it’s not a strategy I would recommend because I’m moving away from the markdown-it parser. The two rules you are concerned about have already been migrated, so this would not help.

I do not think this is a common problem, so I am reluctant to add infrastructure for it. I don’t know of any other linters that support this kind of thing, but would be happy to review links if there is precedent.

If you are using the library directly, then instead of passing it files, you could perform the transformation yourself and have it lint those strings instead.

Or if I’ve misunderstood the proposal, please let me know!

@DavidAnson commented on GitHub (Feb 26, 2024): Fundamentally, you are trying to use a Markdown linter on something that isn’t (yet) complete Markdown. Per my comment in the other issue, I think it’s better in the abstract to lint the final document. Leaving that aside, what I think you are proposing is to create a markdown-it plugin that fills in the referenced content at parse time. It is possible to use such plugins with the VS Code extension, but it’s not a strategy I would recommend because I’m moving away from the markdown-it parser. The two rules you are concerned about have already been migrated, so this would not help. I do not think this is a common problem, so I am reluctant to add infrastructure for it. I don’t know of any other linters that support this kind of thing, but would be happy to review links if there is precedent. If you are using the library directly, then instead of passing it files, you could perform the transformation yourself and have it lint those strings instead. Or if I’ve misunderstood the proposal, please let me know!

kerem commented

2026-03-07 20:08:05 +03:00

Author

Owner

@heaths commented on GitHub (Feb 27, 2024):

I totally appreciate it. It was a long shot and not critical nor do I have time to work on a solution. I appreciate the thought!

@heaths commented on GitHub (Feb 27, 2024): I totally appreciate it. It was a long shot and not critical nor do I have time to work on a solution. I appreciate the thought!