Php-cs-fixer: Add a switch to print fixed code to stdout.

[naquad]

I'm trying to use php-cs-fixer as a filter program so i need it to accept input on stdin and print output on stdout, but it doesn't. It would be super awesome if it had a switch to just print the resulting code to make similar invocation possible:

cat some_code.php | php-cs-fixer fix --stdout -

[keradus]

@naquad could you provide a PR for this feature ?

[naquad]

I didn't implement it. I don't know PHP-CS-Fixer maintainer that knows code would do it much faster then someone who needs to explore current code first.

[keradus]

It is not a bug report, it's a feature request. The idea of contributing is to allow everyone to contrib.
Indeed, someone who know the code alread might do it few minutes faster, but you have greater motivation :)
It would be great if you want to implement this feature! If not then maybe, maybe sb else do it one day.

[keradus]

Is there anyone who want to have that feature?

[jian-wu]

I don't see a huge advantage having this support than reading from the fixed file.

[lxg]

@keradus

Is there anyone who want to have that feature?

Yes, this would really be a great feature. Outputting PSR-2 fixed code to STDOUT would be great for usage within IDEs, e.g. Bluefish and Kdevelop allow passing files and file chunks through filters. Would be great to be able to format the code of an open file with a simple key stroke in the IDE.

Btw, I would try to write a patch/PR if you could give me a starting point where to look.

[keradus]

file chunks through filters

most fixers wont work on file chunks

[lxg]

@keradus: Ok, it was just an example. Anyway it would be very helpful to have support for STDIN/STDOUT. Pressing a key to have a complete file properly formatted, would help a lot. Every decent IDE has this feature, and _php-cs-fixer_ is a great tool for PSR-2 compliant PHP code formatting.

[keradus]

BTW support of stdin is already implemented. Just the stdout is currently the same as in dry-run mode and you need here a full file on output and non other information (what is BC break).

https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/1.9/Symfony/CS/Console/Command/FixCommand.php#L277

[lxg]

Uh, ok ... but it's pretty useless at the moment. The only output is

$ cat SomeFile.php | php-cs-fixer fix -
1) stdin.php
Fixed all files in 0.084 seconds, 6.500 MB memory used

What is that good for?

[keradus]

That is why I said what is currently and what need to be changed (and that is that BC break you need to make)

[lxg]

Ok, I'll write a patch. Do you think it is better to send the debug information (“_Fixed all files in 0.084 seconds, 6.500 MB memory used_”) to STDERR or to omit it altogether?

[keradus]

Wouldn't it already printed on stderr ?

[lxg]

Nope. Everything is sent through $output which is mapped to STDOUT. Also, appending 2>/dev/null to the command line still show everything. But, no problem, I'll fix that, too.

[SpacePossum]

(writing to STDERR is done/fixed on master/2.0)

[keradus]

And @lxg need to use master due to BC break

[lxg]

@SpacePossum: Only Progress is written to STDERR. “Loaded config …” and “Fixed all files …” messages as well as the list of fixed files are still written to STDOUT. I would propose to write only “payload” information to STDOUT, i.e. streams of fixed code. Informational text should go to STDERR. This is like most other command line tools behave (e.g. _wget_). Or, alternatively, don't print any informational text unless the verbosity level is at least 2?

[SpacePossum]

If https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1247 makes it into 2.0 a new (custom) output class can be made to that will be the only one writing to STDOUT.

[keradus]

This thread is dead.
Closing due to lack of interest by anyone.

[ghost]

@lxg wrote:

Do you think it is better to send the debug information (“_Fixed all files in 0.084 seconds, 6.500 MB memory used_”) to STDERR or to omit it altogether?

When present, it should be written to STDERR. If it is output by default, then the user should be able to silence it with a --quiet option. (Conversely, if it is not output by default, then the user should be able to enable it with a --verbose option.)

[ghost]

Please can this issue be reopened? It has not been fixed.

The following remarks are follow-up from #1579, which is one of several duplicates of this issue.

@stof [wrote]:

cat file > php-cs-fixer fix - should do the work

This, of course, is wrong, because > is an inappropriate shell redirection character to use here. Rather than piping the contents of file to the command php-cs-fixer, it would instead write the contents of file to a file called php-cs-fixer, creating the latter if necessary. But even we we use | instead of > per @gharlan 's correction of @stof's error, the functionality requested in @garak's opening comment ("I don't want to pass a path and get the file(s) on that path to be fixed, I want to pass a content as stdin and get the fixed content as stdout") is still not fully present:

$ cat 1.php | php-cs-fixer fix --dry-run -
Loaded config default.
Using cache file ".php_cs.cache".
   1) php://stdin

Checked all files in 0.197 seconds, 12.000 MB memory used

As you can see, PHP-CS-Fixer accepts STDIN, which is good. But rather than sending to STDOUT, as desired, the fixed version of the PHP code that it received via STDIN, PHP-CS-Fixer instead sends STDOUT some lines of metadata that would more appropriately be sent to STDERR.

I think it is also worth gently noting that @stof's comment:

use the --diff option to get the diff in the output

while presumably well-intentioned, was essentially off-topic, because @garak's post was about retrieving the fixed PHP code via stdout, not about retrieving a diff via stdout.

The PHP version you are using ($ php -v):

7.0.27-0+deb9u1

PHP CS Fixer version you are using ($ php-cs-fixer -V):

PHP CS Fixer 2.12.0 Long Journey by Fabien Potencier and Dariusz Ruminski (a53f39a)

[keradus]

Writing (basically the same content) to 5 different, years old (like here, 4!), issues, is not helpful at all - be glad that anyone saw that.
Also, content provided by you does not give any new value, @sampablokuper .

Issues, as claimed during closing them, were not closed because feature was implemented, but because, after initial alignment, nobody was interested in them anymore.

If you want to change that, simply raise a PR.

[akalongman]

+1 for this feature

[SpacePossum]

Please open a new issue/PR, a lot has changed since this was discussed so lets start fresh and see what can be done now :)