Closed fredden closed 3 months ago
@fredden Thanks for suggesting this, but I'm not terribly keen on this change (quite apart from having serious doubts about the proposed change working the way you seem to expect it would).
Let's think this through:
Now what about PHPCBF ?
All in all, this change does not fill me with confidence.
As per the CONTRIBUTING guide, maybe this topic (and all potential angles and potential problems this can cause) should be discussed in an issue instead ?
I will test this more locally. The lack of test coverage means that this sort of change is risky.
I will test this more locally. The lack of test coverage means that this sort of change is risky.
Exactly, which means I would not accept this change without significant test coverage being added.
@fredden and me discussed this PR in a call. Basically, this PR is blocked until the cache feature has proper (full) test coverage, so we can be sure nothing breaks with this change.
Closing this PR until those preliminaries are fulfilled. Once they are fulfilled, I'm perfectly happy to revisit this PR and re-open it.
Description
As part of the development process, I often find myself using
phpcbf
followed byphpcs
in order to check that the code I've written complies with the configured coding standard for the codebase in question. I have recently also started using the--cache
parameter on the command-line to speed up this process. This has a significant positive impact on the time taken forphpcs
, howeverphpcbf
seemed to take the same time as usual.This pull request enables
phpcbf
to use the cache, just likephpcs
does. In my use-case where I runphpcbf
immediately followed byphpcs
(with the same flags), thephpcs
run is always very fast as it can use the cache and doesn't need to re-scan every file.Suggested changelog entry
phpcbf
to use the cacheTypes of changes
PR checklist
Fixes #485