Implemented Provide official PHP CS Fixer Config

K

Kirby

Well-known member
I suggested this already somewhat like 5 years ago but it was rejected due to Lack of Interest:
K

Lack of interest Thread 'Priovide Official PHP CS Fixer Config'

Re-Post of https://xf2demo.xenforo.com/threads/official-php-cs-fixer-config.3023/ so it does not eventually get lost:

It would be great if you could provide an official .php_cs.dist which Add-on developers could use to verify that their code is fully compliant with XF Code Style.
  • Like

XenForo

Thread 'XenForo 2.3.0 Release Candidate 4 & Add-ons (Release Candidate 3) Released (Unsupported)'

This week in addition to a bunch of bug fixes, we've also been doing a spot of housekeeping in our code. The following is quite technically heavy so if you're a non-developer, shield your eyes and read the less boring bits.

Much wider usage for class strings​

As a reminder, XenForo 2.3 brings with it support for using native PHP class strings. For example, originally we used "class short names" to point to certain classes. While these were easy to write, it makes refactoring classes difficult, and you need these PHP doc comments to hint to code editors what object is ultimately...
  • Like
  • Love

Now that XenForo (finally!) actively uses PHP CS Fixer
We have also made some other wide ranging changes across the code as a result of automatically running PHP CS Fixer. On the whole this doesn't change much, but if you're the type of person who has your XF files in a GitHub repo, you will see a lot of changes, but these are mostly just trying to make the overall code base a little easier to read, follow and overall more consistent.
Click to expand...

It would be really appreciated if you could publish the config so 3rd party developers can also make their code consistent with XenForo code base.
 
Upvote 9
This suggestion has been implemented. Votes are no longer accepted.
Yeah this is planned.

For the avoidance of doubt, part of the reason it would have been "lack of interest" is because we weren't actually using PHP CS Fixer until this release cycle.

We've been somewhat softly using it since one of the more recent betas, we used it a little more to drive consistency with our class strings and imports for RC3/4 and RC5 finally introduces some more wide ranging and opinionated formatting changes to make the code base more consistent, and finally enforcing things we like, such as trailing commas in arrays, blank lines at the ends of files etc.

We don't have anything to share right now but we have a bunch of custom rules too which are currently in a private repo. This needs a little tidying up but once we have made some changes we'll make that repo public along with our config.

Then we can all be on the same page :)
 
Last edited:
Chris D said:
Yeah this is planned.

For the avoidance of doubt, part of the reason it would have been "lack of interest" is because we weren't actually using PHP CS Fixer until this release cycle.

We've been somewhat softly using it since one of the more recent betas, we used it a little more to drive consistency with our class strings and imports for RC3/4 and RC5 finally introduces some more wide ranging and opinionated changes formatting changes to make the code base more consistent, and finally enforcing things we like, such as trailing commas in arrays, blank lines at the ends of files etc.

We don't have anything to share right now but we have a bunch of custom rules too which are currently in a private repo. This needs a little tidying up but once we have made some changes we'll make that repo public along with our config.

Then we can all be on the same page :)
Click to expand...
Give It To Me Want GIF


Also please include instructions for how to run the custom rules in a GitHub Action workflow 👍
 
DragonByte Tech said:
Also please include instructions for how to run the custom rules in a GitHub Action workflow 👍
Click to expand...
I think we can probably provide our configuration for that too.

That's what we're doing now as of this morning :)

BTW I thought it worth mentioning: some of these changes are later in the release cycle than we'd have liked, mostly because we've had to juggle when the right time to do this would be. We (were) actively developing three XF versions, 2.2, 2.3 and 3.0 and naturally the thought of making sweeping changes to the code which would then make integrating changes upstream and downstream extremely challenging was not attractive.

Our choices were to do it after what should be the last 2.2 release, or wait until we were nearly done with 3.0 (by which point we'd still be maintaining 2.3 and potentially even working on 3.1).

So the recent changes were significant and not ideal but for the most part had to be done at some point and we decided on balance it was better to do them now than to wait until much later.

It was unfortunate that RC3 broke some add-on stuff (which was fixed with RC4) but in all cases the changes we've implemented have changed the structure of the code but not actually the functionality and should (now) be fully backwards compatible, so for all intents and purposes, nothing here should actually require you guys to make changes. Unless you want to, but then of course tools like PHP CS Fixer will no doubt help with that. But most of you are big fans with maintaining backwards compatibility in your add-ons, so continuing to use class short names is perfectly valid and should continue to work without any changes.
 
Chris D said:
So the recent changes were significant and not ideal but for the most part had to be done at some point and we decided on balance it was better to do them now than to wait until much later.
Click to expand...
Not gonna lie, it did throw a bit of a wrench in my plans of releasing beta versions of my addons for 2.3 since I want to dogfood at least some of them for a bit before releasing them 😅

Chris D said:
Unless you want to, but then of course tools like PHP CS Fixer will no doubt help with that.
Click to expand...
Personally I don't want to deal with BC because it inevitably results in needing some kind of hack :P 2.3 and PHP 8.0 going forward, I'm doing my part towards a future where XF can take advantage of a non-EOL version of PHP and its capabilities 🤣
 
Awesome :cool:

One question though:
Why did you choose to have as in uppercase?

Seems to be somewhat inconsistent to me as all other keywords are lowercase.
 
Practicality I guess. That decision was made a decade before I was here and I chose to write the rules to match as closely to what we already had as possible to hedge my bets that we'd actually adopt it.

You can disable it if you want:
PHP: 
$config = (new ConfigHelper($finder))->getConfig();

$config->setRules(array_merge(
    $config->getRules(),
    [
        'XF/uppercase_foreach_as' => false,
    ]
));

return $config;
 
Fair enough, I thought providing a customization example for our config helper might be useful, at least to somebody.

I find it a bit odd myself but as long as it's consistently applied I'm not especially bothered :) Maybe someone else has the answer.
 
How does one know when using PHPStorm after inspecting a code base which ruleset the warning/error is coming from? The drop down in the image below doesn't show a XFCS option.
1729889482518.webp
 
PHP CS Fixer doesn't support named custom rulesets, only custom configurations. You need to select custom and point it at your configuration file, created per the usage instructions in the repository.
 

Similar threads

Jarvis
XF 2.2 Access OAuth config from within Provider Service
Replies
5
Views
1K
Mike
Mike
K
  • Suggestion Suggestion
Lack of interest Priovide Official PHP CS Fixer Config
Replies
2
Views
705
kick
K
Back
Top Bottom