Support --stdin with --fix

[orhun]

Hello! 👋🏼

I maintain a project called git-cliff, which is used mostly for generating changelogs in markdown format. We also support postprocessors for running certain commands after the file is generated.

My use case is to run markdownlint-cli to fix the styling issues like so:

postprocessors = [
  { pattern = '.*', replace_command = 'markdownlint --fix --stdin' },
]

However, this does not work since the flags cannot be used together. I simply need to read content from stdin and print out the "fixed" content to stdout.

Would it be plausible to support this use case?

[DavidAnson]

If I understand your scenario correctly, the issue is not that those two options aren't compatible, but that you want a new feature which is to output the result of fixing a file to standard output - and presumably not also output status or information about unfixable errors. is there a reason you aren't able to do this today by using a temporary file instead?

[orhun]

Yup, you are correct.

is there a reason you aren't able to do this today by using a temporary file instead?

That would mean I need to run multiple commands to do one operation which means it will over-complicate the configuration above.

As a reference, take a look at what I do with the typos tool to fix typos:

{ pattern = '.*', replace_command = 'typos --write-changes -' },

Additionally, I believe supporting cat file.md | markdownlint --stdin --fix would also be nice for using markdownlint in shell scripts for quickly fixing the style of a file.

[DavidAnson]

If I understand both of your examples above, you have an existing file on disk that you want to apply fixes to. In the first example, it's files that match that pattern and then you are writing changes back to disk. In the second, it's the file being cat-ed and I assume the result is going to be redirected to some file in the next step. It seems to me that both examples should be possible today. I agree stdin-stdout is a potential workflow, but I am still not clear on when it is needed?

[orhun]

it's files that match that pattern and then you are writing changes back to disk.

Not quite correct. It's regex-matching the contents of a buffer instead of a file. (See preprocessors for more information.)

So at the time that markdownlint is being run there isn't a file saved on the disk.

In the second, it's the file being cat-ed and I assume the result is going to be redirected to some file in the next step.

Both of the approaches are the same so it simply reads some content from stdin and write the fixed one to stdout. It can either be redirected to a file or not.

It seems to me that both examples should be possible today. I agree stdin-stdout is a potential workflow, but I am still not clear on when it is needed?

Unfortunately it's not possible due not being able to output the result to the stdout.

You can try it for yourself:

$ cat CHANGELOG.md | markdownlint --stdin --fix

Usage: markdownlint [options] <files|directories|globs>

MarkdownLint Command Line Interface

Options:
  -V, --version                              output the version number
  -c, --config <configFile>                  configuration file (JSON, JSONC, JS, YAML, or TOML)
  --configPointer <pointer>                  JSON Pointer to object within configuration file (default: "")
  -d, --dot                                  include files/folders with a dot (for example `.github`)
  -f, --fix                                  fix basic errors (does not work with STDIN)
  -i, --ignore <file|directory|glob>         file(s) to ignore/exclude (default: [])
  -j, --json                                 write issues in json format
  -o, --output <outputFile>                  write issues to file (no console)
  -p, --ignore-path <file>                   path to file with ignore pattern(s)
  -q, --quiet                                do not write issues to STDOUT
  -r, --rules <file|directory|glob|package>  include custom rule files (default: [])
  -s, --stdin                                read from STDIN (does not work with files)
  --enable <rules...>                        Enable certain rules, e.g. --enable MD013 MD041 --
  --disable <rules...>                       Disable certain rules, e.g. --disable MD013 MD041 --
  -h, --help                                 display help for command

Hint: #104 (which I think should be fixed as well.)