Allow phpcbf to use the cache

[fredden]

Is your feature request related to a problem?

Yes and no. When using phpcs --cache, subsequent runs are fast. When using phpcbf --cache, every run takes the same amount of time as the first.

Describe the solution you'd like

When using phpcbf --cache, subsequent runs should be faster - as they already are with phpcs --cache. Also, when using both phpcs and phpcbf, the cache generated by one should be usable by the other.

The following table shows the behaviour that I expect. Here "empty cache" means that the file being scanned either has no entry in the cache, or its entry is somehow invalid (eg, the file content has changed).

Scenario	phpcs (cache miss)	phpcbf (cache miss)	phpcs (cache hit)	phpcbf (cache hit)
No errors	Run ruleset, find no errors, save result in cache	Run ruleset (with fixers), find no errors, save result in cache	Report (no) errors, do nothing with cache	Detect that there are no fixable errors (in cache entry), no other action
Only fixable errors	Run ruleset, find some errors, save result in cache	Run ruleset, find some fixable errors, fix errors, do nothing with cache	Report errors, do nothing with cache	Detect that there are fixable errors (in cache entry), run ruleset (with fixers), do nothing with cache (or maybe actively remove the now-stale entry)
Fixable and unfixable errors	Run ruleset, find some errors, save result in cache	Run ruleset, find some fixable errors, fix errors, do nothing with cache	Report errors, do nothing with cache	Detect that there are fixable errors (in cache entry), run ruleset (with fixers), do nothing with cache (or maybe actively remove the now-stale entry)
Only unfixable errors	Run ruleset, find some errors, save result in cache	Run ruleset (with fixers), save result in cache	Report errors, do nothing with cache	Detect that there are no fixable errors (in cache entry), no other action

Additional context (optional)

Given the low test coverage of the areas in question here, making changes to this functionality is risky. Therefore this feature is likely blocked by #146 and/or #147

Some initial work can be seen here: #481

• I intend to create a pull request to implement this feature.

[jrfnl]

Thanks for opening this issue @fredden. You already know my opinion: this is more complicated than you initially thought.

If I look at the table above, I still see logic logic errors.

If the caching feature is active, the cache at the end of a run should always be complete and correct, so in my opinion, your entries in the "Only fixable errors" and "Fixable and unfixable errors" rows for phpcbf are incorrect.

In the mean time, let's close #481.

[fredden]

@jrfnl let's discuss this on our next call. I am interested to learn about these logic errors that you hinted at. I think that the implementation in #481 matches the table above.

[mabar]

Wouldn't it be possible to start small? Just skip the files that are already cached and with no errors if unmodified since last phpcs run.
Even if it does not update the cache and re-runs for fixed files before phpcs is ran again, it would still make fixing few files in codebases with 1000+ files significantly faster and not break anything.
And updating the cache would be as simple as running phpcs again.
It would be far from perfect but from my (possible naive) point of view it would do 90% of the results for 10% of the work, with very little (possibly none?) risk involved.

[fredden]

In my call with @jrfnl, we determined that there are not actually any logic errors, but instead the language used was confusing. I will review the words/language to better communicate the intent.

[jrfnl]

Just came across old repo issue squizlabs/PHP_CodeSniffer#3781 and I think that needs to be looked into in relation to this ticket as it gives the impression that - at least in some cases - the cache is already being taken into account for PHPCBF....