Implemented Provide official PHP CS Fixer Config

[Kirby]

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'

Aug 12, 2017

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.

• Kirby
• Replies: 2
• Forum: Closed suggestions

• 

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

Jun 14, 2024

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...

• XenForo
• Replies: 1
• Forum: Announcements

• 
• 

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.

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.

 

[Chris D]

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

 

[DragonByte Tech]

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

Also please include instructions for how to run the custom rules in a GitHub Action workflow

 

[Chris D]

Also please include instructions for how to run the custom rules in a GitHub Action workflow

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.

 

[DragonByte Tech]

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.

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

Unless you want to, but then of course tools like PHP CS Fixer will no doubt help with that.

Personally I don't want to deal with BC because it inevitably results in needing some kind of hack 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

 

[Kirby]

This needs a little tidying up but once we have made some changes we'll make that repo public along with our config.

As 2.3 final has been released:
Where can we find the config?

 

[Chris D]

Nowhere yet.

 

[DragonByte Tech]

 

[Jeremy P]

Here you go:

GitHub - xenforo-ltd/xf-cs-fixer: A PHP Coding Standards Fixer configuration for XenForo

A PHP Coding Standards Fixer configuration for XenForo - xenforo-ltd/xf-cs-fixer

github.com

 

[Kirby]

Awesome

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.

 

[Jeremy P]

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:

$config = (new ConfigHelper($finder))->getConfig();

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

return $config;

 

[Kirby]

You can disable it if you want

Yeah, I know - we've been using PHP CS Fixer (with a custom made rulset) for ages.

I just wanted to know why it is the way it is as it feels strange to me

 

[Jeremy P]

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.