Php-cs-fixer: Proposal: .php_cs.lock with list of fixers being (and not) applied

[kalessil]

It would be helpful to have this file dumped after each CS Fixer run (similar to composer.lock file).
E.g. for Php Inspections (EA Extended) to not apply "last comma in array" inspection to source code - just read the file and don't bother developers with extra setting management.

Some rough ideas for structure:

header_comment=yes
long_array_syntax=yes
strict=no

[GrahamCampbell]

Very interesting idea. I'd vote for having it json formatted, like composer does.

Ping @bobthecow - you were concerned over bc breaks due to us introducing new fixers. This might be a good solution for you.

[GrahamCampbell]

@kalessil A better way to do this as far as I'm concerned is for the lock file to just have the fixers to apply, rather than the whole yes/no deal, so we can just skip straight to that list instead of going through the config resolver like we do at the moment.

[kalessil]

@GrahamCampbell : for the format it would be better ini/xml format as PHP/Java has functions from the box to work with these formats. To keep only applied fixers in lock file will work for me.

For file structure it can be more useful options: excluded resources (folders and files), preset id (psrN, Symfony). Maybe something else to state version/BC meta-data.

[kalessil]

Update: JSON is fine, there is lightweight library for java - just ~20KB.

[bobthecow]

:+1: Lock file sounds good to me, that'd fix all my concerns :)

[keradus]

Regenerating this file after each PHP CS Fixer run is pointless - it must be generated once and then used. yaml is good with me too.

@GrahamCampbell , maybe create one such lock file and then no need to have it duplicated into StyleCI configuration?

One more thing: sb configured fixers inside .php_cs, then store it in lock file and change configuration. When running a fixer we will taki list from lock file even when config change ? And what if one run a fixer with --fixers option?
Such a lock file must be generated on demand, not always. Remember that there will be users that want to use full level like PSR2 or Symfony - even when new fixer appear.

[bobthecow]

Something like npm shrinkwrap then?

[kalessil]

Maybe one step further: declarative cs_fixer.json as composer again, and then lock-file just to state BC meta-info?

Then I can just use manifest and adjust my inspections accordingly, without any workarounds.

@keradus : then lock-file is optional and used to make configuration diffs (for whatever purposes - needs to be defined).

[keradus]

Maybe one step further: declarative cs_fixer.json as composer again, and then lock-file just to state BC meta-info?

You say to replace .php_cs with cs_fixer.json ?
No. One is PHP, one is JSON. You can't do all with JSON.

[kalessil]

@keradus : in .php_cs it's possible to specify preset, exclude some directories/files, add extra fixers. What else can be there what is not possible to make "declarative"?

I can even make a prototype dumping declarations from .php_cs to cs_fixer.json and loader for it.

[keradus]

Fiddle with Config and it properties, eg applying sth on finder (like filtering), conditional settings, including other files (like .php_cs.local when we don't have .php_cs.dist). And so on so on...

https://github.com/zendframework/zf2/blob/master/.php_cs#L23
https://github.com/bobthecow/mustache.php/blob/dev/.php_cs#L15

[kalessil]

Affirmative, then only lock file is option for 3rd parties.

It's actually means regeneration of the lock file after each run to be sure it's up to date.
VCS shall be fine with this and overhead shall be not so big one.

[keradus]

:-1: for regenerating on each run - then it will be no benefits to have both files, if config is always used and lock is always regenerated
:-1: for VCS

[kalessil]

Ok, even if it's generated on demand, it's better than nothing at all =)

[GrahamCampbell]

:-1: for replacing the .php_cs file. I actually see this being useful as an actual lock file, like composer has, so that we can guarantee the same fixers are used between versions.

[GrahamCampbell]

Also lock files would have nothing to do with StyleCI?

[keradus]

@GrahamCampbell
I am thinking about sth that can be common between PHP CS Fixer and StyleCI. And that lock file could be that thing

[kalessil]

Structure from .styleci.yml would fit as for me (but in JSON as I mentioned already) + version

preset: name
version: 1.6
enabled:  
  - strict
  - strict_param
  - others expanded from preset

disabled:  
  - short_array_syntax

[kalessil]

@GrahamCampbell : what about excluded resources? How it makes sense to define them?

[GrahamCampbell]

I am thinking about sth that can be common between PHP CS Fixer and StyleCI. And that lock file could be that thing

Nah. We're totally ignoring anything php-cs-fixer does with config atm. We're rolling out own system, and have no plans to change.

[GrahamCampbell]

what about excluded resources? How it makes sense to define them?

That's exactly the problem. You can't atm.

[keradus]

I see.

Then I can't see any benefit of that lock file. Everything that could be possible with lock file is possible with current config file.

[bobthecow]

Everything you can do with the Composer lockfile you can do with composer.json.

[GrahamCampbell]

@keradus I see the lock file as being useful to lock the fixers to use, and nothing more. IE, it's not the same as composer's lock file that contains all the information needed.

[keradus]

yeah, but one can lock fixers with .php_cs as well.

[GrahamCampbell]

@keradus Yes, but that's not convenient. They;d have to manually go and check what fixers are new with each release, instead of just running a single command to update the lock file.

[keradus]

OK. If anyone willing to take it go ahead ;)

[bobthecow]

yeah, but one can lock fixers with .php_cs as well.

one can lock dependencies with composer.json as well … but that doesn't mean it's the most effective and convenient way to do it ;)

[kalessil]

If it will be no volunteers, I could start with it, but it will be earliest mid of April (is_null() fixer first).

[keradus]

Anyone willing to create PR for this issue?

After introducing RuleSet and FixerFactory is should be a bit easier.

[schmunk42]

what about excluded resources? How it makes sense to define them?

That's exactly the problem. You can't atm.

Is excluding resources covered by this issue or is there a separate one? It's a feature I really miss.

[SpacePossum]

Is excluding resources covered by this issue or is there a separate one? It's a feature I really miss.

what kind of resources would you like to exclude which cannot be excluded by the current configuration file?

[schmunk42]

I was looking for some docs of the config file but found nothing helpful.

Can I create a .php_cs file with

exlude=somedir

What's the exact syntax?

[SpacePossum]

Maybe this is an handy example; for this project we use the following to exclude the fixtures directory;
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/v1.12.4/.php_cs#L31

The way this works is that the returned object by the config extends the Symfony Finder class.

[schmunk42]

Thank you! I will try this. Didn't exepect .php_cs to be a PHP-file :)

[julienfalque]

Reading the discussion I don't see any benefit of having some lock file like Composer does.

IMO the solution is to lock the version of PHP CS Fixer that is installed with composer.lock so that one can choose when to update it and update the config file together, if needed. A specific constraint (e.g. 2.16.*) in composer.json can be used if the lock file is not versioned like in most lib projects.