[GH-ISSUE #1979] Expose fix mode to custom rules (params.fixMode) #2643

New issue

Open

opened 2026-03-07 20:09:36 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 20:09:36 +03:00

Owner

Originally created by @chalin on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1979

Custom rules can emit fixInfo, but they currently can’t reliably detect whether the run is check-only or fix-enabled.

For rules with expensive fix-only logic, this matters:

Check runs should stay fast and avoid unnecessary side effects/rate limits
Fix runs should do the extra work

Today, a workaround is process.argv.includes('--fix'), which is brittle in non-CLI/programmatic contexts.

Feature request:

Add a run-mode signal to custom rule params (for example params.fixMode: boolean)
Document it in doc/CustomRules.md

Environment:

markdownlint 0.40.0
markdownlint-cli2 0.21.0

Thanks for such a great tool!

Originally created by @chalin on GitHub (Feb 24, 2026). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1979 Custom rules can emit `fixInfo`, but they currently can’t reliably detect whether the run is check-only or fix-enabled. For rules with expensive fix-only logic, this matters: - Check runs should stay fast and avoid unnecessary side effects/rate limits - Fix runs should do the extra work Today, a workaround is `process.argv.includes('--fix')`, which is brittle in non-CLI/programmatic contexts. Feature request: - Add a run-mode signal to custom rule params (for example `params.fixMode: boolean`) - Document it in `doc/CustomRules.md` Environment: - markdownlint 0.40.0 - markdownlint-cli2 0.21.0 Thanks for such a great tool!

kerem added the

question

label

2026-03-07 20:09:36 +03:00

kerem commented

2026-03-07 20:09:37 +03:00

Author

Owner

@DavidAnson commented on GitHub (Feb 24, 2026):

I see what you're getting at with this, but two things make me reluctant to implement something like this:

My experience is that most fix code is pretty trivial once a rule has run its detection logic and computed any relevant ranges to log the issue. So I claim the incremental cost of providing fix info is negligible most/almost all of the time. Off the top of my head, I claim none of the built-in rules involve expensive fix logic, though I would be happy to consider examples if you have some in mind.
Some scenarios – notably the Visual Studio Code extension – would always run in fix mode which means this optimization has no benefit. Arguably, the interactive Nature of the Code extension is the most performance critical of all, so if implementing this feature encouraged people to write fix code that was slow to run, that would be counterproductive.

@DavidAnson commented on GitHub (Feb 24, 2026): I see what you're getting at with this, but two things make me reluctant to implement something like this: 1. My experience is that most fix code is pretty trivial once a rule has run its detection logic and computed any relevant ranges to log the issue. So I claim the incremental cost of providing fix info is negligible most/almost all of the time. Off the top of my head, I claim none of the built-in rules involve expensive fix logic, though I would be happy to consider examples if you have some in mind. 2. Some scenarios – notably the Visual Studio Code extension – would always run in fix mode which means this optimization has no benefit. Arguably, the interactive Nature of the Code extension is the most performance critical of all, so if implementing this feature encouraged people to write fix code that was slow to run, that would be counterproductive.

kerem commented

2026-03-07 20:09:37 +03:00

Author

Owner

@chalin commented on GitHub (Mar 2, 2026):

Hi @DavidAnson. Thanks for the prompt reply with the context. I'm OOO for a few weeks. I'll share my motivating use case when I'm back.

@chalin commented on GitHub (Mar 2, 2026): Hi @DavidAnson. Thanks for the prompt reply with the context. I'm OOO for a few weeks. I'll share my motivating use case when I'm back.