Php-cs-fixer: alternative config file

[glensc]

would be cool if php-cs-fixer supported a .php extension, besides current .php_cs

the reason for this is that file type detection would be correct:
1) subversion auto properties setting proper mime type
2) various editors and IDE's that use *.php glob for syntax hiliting
3) php-cs-fixer itself fails to identify .php_cs as php file and skipping fixing it
4) ...

i guess it should use .php_cs, if that is not found, try .php_cs.php

[keradus]

Any other opinion?

We already have .php_cs and .php_cs.dist, then having .php_cs.php and .php_cs.dist.php is pointless.

We also have .php_cs.cache, which is json, but not with json extension.

These files shouldn't be changes ofter, and if someone want he could always teach his IDE etc to treat them like regular php file.

Personally I would not change it. It is a config file, not a regular php file.

[keradus]

Very wel,.. closing then.

[glensc]

(sorry, could not comment earlier, was on a vacation trip)

meh. pointless? i explained the "point".

you could make previous names deprecated and stick to new naming scheme.

i listed only two points where it can go wrong, there are more places where file should be treated as php not text file (typeless file?)

[glensc]

please reconsider adding .php extension support as well.

currently even default finder doesn't pick up .php_cs file to process it, not to mention the earlier file type by extension detection pointed out earlier by other tools.

also .php_cs.cache is not json, it's PHP serialized data.

and telling to configure systems, editors to use .php_cs extension for php file type is not valid point. there may be too many systems, and configs to change especially if the change needs to be done per project and there are hundreds of projects.

[SpacePossum]

also .php_cs.cache is not json, it's PHP serialized data.

On 1.x line yes on 2.x no. So you are both right :)

.php_cs.dist support is also on 2.x only (ref.).

With .php_cs and .php_cs.dist it is clear which files should be tested for first and if both found which one should be used and which one ignored.
When adding other options like .php_cs.php and/or .php_cs.dist.php I wonder how the order of testing should be.

| .php_cs | .php_cs.dist | .php_cs.php | .php_cs.dist.php | use |
| --- | --- | --- | --- | --- |
| | | | | build in default config |
| | | | 1 | .php_cs.dist.php |
| | | 1 | | .php_cs.php |
| | | 1 | 1 | .php_cs.php |
| | 1 | | | .php_cs.dist |
| | 1 | | 1 | ? |
| | 1 | 1 | | ? |
| | 1 | 1 | 1 | ? |
| 1 | | | | .php_cs |
| 1 | | | 1 | ? |
| 1 | | 1 | | ? |
| 1 | | 1 | 1 | ? |
| 1 | 1 | | | .php_cs |
| 1 | 1 | | 1 | ? |
| 1 | 1 | 1 | | ? |
| 1 | 1 | 1 | 1 | ? |

(to be clear, I'm not against the idea of adding the .php version of the configuration file(s), but am I wondering how this would work)

[glensc]

where can i read how .php_cs and .php_cs.dist are currently handled?

• are they "merged" and in what order?
• are they "used on first pick"?

[glensc]

as for new policy, depends what does the project recommend itself to use: .php_cs or .php_cs.php and based on that can probably think of priority of the files.

[SpacePossum]

where can i read how .php_cs and .php_cs.dist are currently handled?

• are they "merged" and in what order?
• are they "used on first pick"?

The configuration files are not merged in any way. The ConfigurationResolver searches for candidate configuration files here. It selects the first valid candidate here to use.
My vote for priority would be: 'user input', php_cs, php_cs.dist, php_cs.php.

[glensc]

@SpacePossum i'm ok with your proposal, as long as the list includes .php extension :)

also if the extensionless form is to be deprecated, there should be .php_cs.dist.php in the list as well.

[keradus]

big :-1: for adding next and next extension. if .php_cs is used defined and .php_cs.dist is repo defined, then adding extension should be to both of them, not only one of them. and that would make 4 files to choose from. pointles.
big :-1: for removing already support for already existing .

eg, where there is phpunit.xml there is also phpunit.xml.dist, and it's not a problem for anyone that xml file has dist extension.

@glensc, I can see your point.
But seriously, issue was raised 1.5 years ago and got no support from comunity.

[glensc]

@keradus if you omit the deprecation part, you will have same amount of filenames to check. but i do not think it's wise idea.

and "pointless" is very lame to say, i've explained several times the problem. this application is not some high performant server that needs every bit of optimization. and i'm sure there are even more "pointless" code already in the repository, if one really wishes to pick on the topic.

[glensc]

and speaking of lameness, then .php_cs is not even processed by php-cs-fixer!

[glensc]

@SpacePossum never use branch links (like master) when referring to code with line numbers. use commit hash or some tag to make permalinks :).

https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/1027#issuecomment-258096095

the line numbers are already off by now.

[keradus]

again, having 2 more files to support without any difference in functionality against current ones is no go, as it will bring confusion which ones will be used.
again, nobody deny value of your points, but you just didn't get any support from community for 1.5 years. think about it.

[glensc]

what community? it's only you here! i'm sure nobody browses closed issues!

[GrahamCampbell]

I think what we have is fine.

[glensc]

please re-consider to add config with .php to default search list, so dogfooding can happen: the phpcs config itself should also be applied the fixer rules!