Php-cs-fixer: Output fixed php to stdout

[FlickerBean]

Google foo and a bit of trial and error has gotten me so far:

cat test.php | php-cs-fixer fix -
Allows stdin! But this doesn't output the fixed php.

cat test.php | php-cs-fixer fix --diff -
Outputs to stdout, but only a diff.

It would be useful to be able to pipe in php, and have the actual fixed up php returned to stdout.

My particular use case is vim, it's awkward to be forced to save a file, before having vim run php-cs-fixer and then have vim auto-reload the modified file.

Much better would be to pipe the contents of the modified buffer into php-cs-fixer and replace it with the returned stdout. Perhaps a --output option?
This would add a lot of flexibility to php-cs-fixer.

:%!php-cs-fixer fix -o - -

[SpacePossum]

I like this idea, not sure about the param name, maybe -o stdOut or something?

[GrahamCampbell]

PHP-CS-Fixer also requires there to be an actual file name for the input to work.

[FlickerBean]

@SpacePossum using - as the output param to signify stdOut is a relatively consistent bash option. wget for example uses this same format.

@GrahamCampbell Does it? If so I don't understand how cat test.php | php-cs-fixer fix --diff - works? Or am I missing the point?

[keradus]

some rules (psr0/psr4) requires it, that's it

[axi]

I ended up creating a new PhpCsFixer\Differ\NewDiffer wich returns only the fixed file

<?php

namespace PhpCsFixer\Differ;

final class NewDiffer implements DifferInterface
{
    /**
     * {@inheritdoc}
     */
    public function diff($old, $new)
    {
        return $new;
    }
}

and modifiing getDiffer() method in ConfigurationResolver

            $mapper = [
                'null' => function () { return new NullDiffer(); },
                'sbd' => function () { return new SebastianBergmannDiffer(); },
                'udiff' => function () { return new UnifiedDiffer(); },
                'new' => function () { return new NewDiffer(); },
            ];

using it with

php-cs-fixer fix --dry-run --diff-format=new

almost ok as it still return

---------- begin diff ----------
new fixed file
      ----------- end diff -----------
Checked all files in 0.772 seconds, 10.000 MB memory used

[SpacePossum]

almost ok as it still return

Sadly we don't allow for configuration of the diff's wrapper, so you always get the ---------- begin diff ----------.

I would like to this to be configurable, especially since we now provide udiff generation it would be nice to generate correct patch files with multiple udiff in it as well.

Without much changes I still think this FR is doable, now we just need to find someone with time ;)

[remorse]

It probably doesn't do everything that php-cs-fixer does, but https://github.com/nanch/phpfmt_stable includes a program that does a lot of reformatting, which can be used as a filter, in case that helps.

[akalongman]

What about this issue?

[keradus]

it's got obsolete, not enough (almost none?) ppl wanted it to happen

[ghost]

This is a duplicate of #454 and should be closed as such, so that discussion can be consolidated there rather than being fragmented over multiple threads.

[FlickerBean]

The discussion on #454 states to open a new issue because a lot has changed. This is a newer issue, and has been closed because the discussion should be continued over there?

[ghost]

@FlickerBean #454 is the original report of this issue. @SpacePossum recently locked and closed #454 erroneously. I subsequently opened #3822 to get that rectified.

Hopefully, it will be rectified soon. If so, then discussion can be resumed at #454, and all later reports of the issue - including this one - closed as duplicates of #454.

[FlickerBean]

Understood, thanks for the update.

[keradus]

@FlickerBean , please ignore @sampablokuper request, 454 will not be opened as super outdated and 3/4 of comments there are not matching current software version

[keradus]

@FlickerBean , @sampablokuper ;
This feature is out of plans of core team - but the feature itself won't be rejected.
Saying that, if you want the feature, we would need to ask you for the help implementing it

[FlickerBean]

Then will this ticket be re-opened or is the recommendation to open another ticket?

[ghost]

@keradus wrote:

This feature ... won't be rejected.

Then why is #454 still closed and locked?

Saying that, if you want the feature, we would need to ask you for the help implementing it

454 is the original report for that issue, and as such is the right place for that help to be provided. As long as it remains closed and locked, PHP-CS-Fixer's maintainers are stymieing potential contributors' ability to help.

[keradus]

@FlickerBean no need for yet another ticket for sure

@sampablokuper we answered you ten times for that question already, sadly, if you gonna say same things over and over again, i had bad feeling that ppl will start to ignore your posts

[ghost]

@keradus wrote:

we answered you ten times for that question already

I addressed the problems with your answers, and you have ignored that.

sadly, if you gonna say same things over and over again, i had bad feeling that ppl will start to ignore your posts

As long as the PHP-CS-Fixer maintainers' pattern of behaviour is to ignore or dismiss constructive, well-meant efforts on something as trivial as consolidating bug reports to smooth the path for a potential future PR, then it would be irrational for me (or anyone else, IMO) to spend substantially more time and effort on a PR itself or anything else relating to PHP-CS-Fixer, lest that effort be similarly ill-received.* So, as long as #454 remains closed and locked, don't expect any contributions from me except as relates to reopening it.

If you want to discourage potential contributors, you are succeeding.

* Marking a constructive, well-intentioned issue report as spam, as you did at #3822, is particularly egregious and insulting.

[SpacePossum]

As long as the PHP-CS-Fixer maintainers' pattern of behaviour is to ignore or dismiss constructive, well-meant efforts on something as trivial as consolidating bug reports to smooth the path for a potential future PR

I'm not even sure all of the maintainers are aware of all of this, so I don't like you judging them all like this.

I addressed the problems with your answers, and you have ignored that.

That is exactly the issue here and it is great to see that it is clear now. We cannot respond to all questions and suggestions spread over multiple (closed) issues. Since we can't it appears we ignored those.
Since I cannot develop such capabilities up to your standard overnight, I suggest the following:
for each question and suggestion we ignored please create an issue with clear summary and I'll try to answer it there.

If you don't want to that is perfectly fine, but this discussion, no matter how well intended, stops here.

[ghost]

@SpacePossum wrote:

I'm not even sure all of the maintainers are aware of all of this, so I don't like you judging them all like this.

To be clear, I was only referring to the maintainers with whom I had interacted.

I suggest the following: for each question and suggestion we ignored please create an issue with clear summary and I'll try to answer it there.

This seems to be another request for me to duplicate existing effort. (Not the same effort as in the previous request, but a request to duplicate existing effort nevertheless.) I will decline that request, as I would expect any reasonable person to do.

If at some point you come to understand or agree with the contributions that I have made to the PHP-CS-Fixer issue tracker, then I look forward to hearing from you.

[garygreen]

Without looking like I'm spamming, but I would just like to put forward my interest for this feature as well.

My use case: creating a VS code extension which php-cs-fixer can take the stdin of and output to stdout so vscode can properly handle fix on saves/formatting etc gracefully. I'm pretty sure a lot of extensions and other development tools would benefit from having basic stdout functionality, even if it's just for one file support for the time being.

@SpacePossum @keradus you mention this is not something the core team would like to implement, but are open to PRs. Could you at least point the community in the right direction for where this kind of code would be implemented and if there's any design considerations that need to be made in order for the PR to be accepted?

[garygreen]

I've submitted a PR #4320 to add basic support for stdout (one file) - could you guys go there and show support if like me your still interested in this.