Support formatting by reading from stdin and printing to stdout

[RafaelKr]

We're currently using https://dprint.dev/ as a formatter.
By using plugins it's able to format a lot of different file types. Based on the file extension it's deciding which formatter to use. This has the advantage that we just need to call one command and every supported file in the whole project is formatted. Also in the IDE we just need to configure one command which is called for format-on-save.

Usually dprint passes the contents via stdin, reads the formatted result from stdout and writes that back to the file.

For Twig files we configured https://github.com/dprint/dprint-plugin-exec/ to call Twig-CS-Fixer. But we need to have a wrapper script which writes the stdin to a temporary file, let Twig-CS-Fixer do the formatting, read the file and print it to stdout. First we used Twig-CS-Fixer to directly write to the file, but then the file is written twice which caused issues for the colleague using VS Code.

You can see the wrapper script implementation at dprint/dprint-plugin-exec#26 (comment)

It would be much better (probably faster and definitely easier on the SSD) to be able to use PHP-CS-Fixer via stdin and get the result via stdout.

Additional References:

• Support formatting by reading from stdin and printing to stdout PHP-CS-Fixer/PHP-CS-Fixer#8309 (Same request for PHP-CS-Fixer)

[VincentLanglet]

Usually dprint passes the contents via stdin, reads the formatted result from stdout and writes that back to the file.

What not changing this behavior instead.

dprint takes a file, get the content, pass it to the tool, get the output and write back to the file.
Just let the tool doing all the job, pass the name of the file and he'll write the code fixed in the file by himself.

It will solve both Twig-Cs-Fixer and PHP-Cs-Fixer issues.

[RafaelKr]

Mainly because this doesn't work well with the IDE integration of dprint (and other formatters).

For the IDE we have the format on save function enabled. This runs the following pipeline:

1. Triggering file save (Ctrl+S) doesn't save the file directly to the disk, but passes the editor content to dprint instead.
2. Based on the file extension, dprint decides which formatter to run.
3. For twig it calls our fix-twig.sh script, passing it the filename as argument and streams the contents via stdin.
4. Now we need to save the file temporarily, so Twig-CS-Fixer has an actual file to work on. (cat - > $TEMP_FILE reads the stdin that fix-twig.sh receives)
5. Run Twig-CS-Fixer on the temporary file. (vendor/bin/twig-cs-fixer lint --report null --fix $TEMP_FILE)
6. Read the file with cat and stream it based on the original extension:

• .html.twig extension: Pass the stream to prettier. This happens via Prettiers stdin stream. Prettier streams the formatted output to stdout.
• any other extension: Write it directly to stdout

7. dprint now receives the contents back from fix-twig.sh
8. The IDE gets the content back and writes it to the actual file

As a graph the content flows something like this:

IDE Editor =[1]=> dprint =[3]=> fix-twig.sh =[4]=> write /tmp/random-name  =[5]=> twig-cs-fixer =[5]=> write /tmp/random-name =[6]=> read  /tmp/random-name (=[6]=> maybe run prettier) =[7]=> dprint => write actual file => IDE shows updated content

So we could completely skip one disk write (step 4) and read (step 6) if we could pass it to Twig-CS-Fixer via Unix Pipes.

Piping is very common in the Unix universe (and also within WSL), there are many CLI programs supporting it (cat, grep, sort, head, tail, less, ...):
https://www.geeksforgeeks.org/piping-in-unix-or-linux/

Something similiar happens when we reformat the whole project, e.g. as pre-commit hook:
dprint reads the entire project file tree and executes formatting for each file type (e.g. extension) for which we have configured a formatter. For twig this means it reads every twig file, saves a copy to temp, runs Twig-CS-Fixer on the temp file, reads it back, maybe runs also prettier and saves the content to the actual file.

[RafaelKr]

Looking inside Twig-CS-Fixer code I might get an idea why it's not that easy to implement. The architecture is built around having the TwigCsFixer\File\Finder, reading files from there, writing stuff based on file paths to cache manager, etc.

That problem with the file path required for cache manager maybe could be worked around with a file path option, like prettier has for example: https://prettier.io/docs/en/options.html#file-path

FWIW, reading from stdin in PHP shouldn't be very hard. Not sure how it works inside Symfony console context, but here's an example how it would work with "plain" PHP:

• https://github.com/ZeroConfig/CLI/blob/master/src/Reader/StandardIn.php
• Usage: https://github.com/ZeroConfig/CLI/blob/master/docs/input/stdin.md
• PHP IO Streams documentation: https://www.php.net/manual/en/features.commandline.io-streams.php

Again, I understand why it's not an easy undertaking and that it would take some time. It's just that our current implementation described above just feels (is) hacky and far from ideal. And working with Unix for 10+ years now pipes just feel natural and elegant.

[VincentLanglet]

Looking inside Twig-CS-Fixer code I might get an idea why it's not that easy to implement. The architecture is built around having the TwigCsFixer\File\Finder, reading files from there, writing stuff based on file paths to cache manager, etc.

Yes, definitely... but PR is welcome if you want to work on it an find a pleasant way to add such feature