The Future of PHP_CodeSniffer

[jrfnl]

Repost from squizlabs/PHP_CodeSniffer#3932:

TL;DR: This repo is being abandoned. The project continues in the PHPCSStandards organisation.

---

Okay, it's time.

About seven months ago, I was given commit access to this repository. At that time, @gsherwood and me had a call and the agreement was that we'd work together through the back log and get 3.8.0 released, which would give me the chance to get insight into his process, the release process and to verify that we were aligned in vision for the future for the repository.
This agreement included, at my insistence, the provision that I would not merge my own PRs and that Greg would preferably also work via PRs for his contributions.

This started off well and I made a plan with a priority-list for which PRs to merge in which order, made lists with on-going and future projects etc and we had two calls in May this year, but I think most of you who have followed the repo closely will have noticed that it ended there.

I'd been trying to get a response, any kind of response, from Greg since beginning of June and have been sending pings at regular intervals with little effect, aside from one short "sorry, no sight on availability" in July.

A few of weeks ago, I have finally received a, just as short, response which basically said that Greg will abandon the project.

I very much respect Greg's decision and would like to thank him for all his tireless work and the years and years he has maintained this package for the benefit of the wider PHP community. He is a true open source hero and I wish him all the best.

Having said that, this is where we are now:

• I only have commit, not admin access to the repo.
• I don't have insight in the release process nor access to PEAR or Packagist for this repo.

With that in mind, I asked Greg to transfer the repository to the PHPCSStandards organisation, which would give me full control.
I also asked him to give me access to Packagist and PEAR.
This would allow for keeping the package in PEAR and Packagist under its current name and should make for a smooth transition for end-users.

Unfortunately, Greg came back to me a week later and conveyed that the Squizlabs company has declined to transfer the repository stating "code ownership" as the reason.

Well, so be it. 🤷

I have now forked the repo to the PHPCSStandards organisation, and spend some time to get it up & running properly and I have registered the repo under the name phpcsstandards/php_codesniffer on Packagist.
Update: The Composer/Packagist name will stay the same.

This is less than ideal as all of the 200.000+ packages which have a dependency on PHP_CodeSniffer will need to update their workflow/composer.json/PHIVE etc.
It means losing all open PRs (with the exception of my own, which I've recreated). It means losing all issues, having to recreate the wiki etc etc.
And even when this repo will be officially marked as abandoned with the PHPCSStandards version marked as its replacement, it still means that the majority of users, who don't watch the repo, will be left to their own devices to figure this out.

So here we are.

For the time being (for as long as I am the sole maintainer), I will merge my own PRs and I will work on getting 3.8.0 released as soon as possible.
As I don't have access to PEAR, nor insight in how to release to PEAR, it will mean dropping support for installations via PEAR straight away. (note: this does not affect the PEAR sniffs)
Support for installation via Composer, PHIVE, PHAR downloads and git clones will continue, though will all undergo name/address changes.

Note: I would recommend waiting to make the switch until the 3.8.0 release has been tagged. Watch releases on the new repo to automatically get notified of this. The changelog will contain the relevant information for making the switch.

It also means that version 4.0 will be released sooner rather than later and that I will automate as much as possible of the release process to allow for more rapid releases.

Going forward, there are plenty of things I would like to improve, both to enhance the end-user experience, as well as to enhance the dev experience for maintainers of external standards. I also have a list of things in mind to try and make the repo more maintainable and make contributing more straight forward.

I have far more ideas than I have time, so I will need help and more importantly, the project will need significant funding, as the amount of work I see ahead of me would leave very little time for paid work, especially considering I also maintain a fair number of the external standards build on top of PHP_CodeSniffer.

I am posting this here in the spirit of openness and I am hopeful that you all will support me in this, both with quality contributions as well as by getting your employers/all those companies which use PHP_CodeSniffer to fund continued maintenance of the project.

Once the dust settles, I will announce more detailed plans for the future and a roadmap for future releases.

In the mean time, please bear with me. I currently still have quite a few other outstanding commitments, so it will take some time before I can free myself up sufficiently, but the repo is open for issues and PRs.

Please note: funding for this project is not a suggestion, but a requirement to safeguard the future of this project and allow for growing the maintainer pool. Without funding, I will not be able to dedicate the time needed to the project, both to move it forward, as well as to coach others to become co-maintainers.
If you want to help, here are channel through which this project can receive funds:

• https://github.com/sponsors/phpcsstandards
• https://opencollective.com/php_codesniffer
• https://github.com/sponsors/jrfnl

If you support me in this, you can indicate this via a 👍 and by getting companies using PHP_CodeSniffer to start funding the project.

If you have any concerns about all this, please raise them by leaving a comment.

And if you have suggestions on how to make the switch-over experience smoother for end-users, please open an issue in the new repo.

Other than that, please join me in thanking @gsherwood for all the years he's kept this project going!

Oh and give @PHP_CodeSniffer on X or @phpcs on Mastodon a follow if you'd like to stay informed.

P.S.: In the interest of transparency, I have so far only merged maintenance related PRs in the new repo. Now this announcement is out, I will start merging functional PRs over the next few days or so.

[dereuromark]

Thank you for the initiative
It sure sucks to have to redo all that as this is quite the hard cut here.
Especially also for consumers or custom sniffer packages depending on the sniffer repo (as I do).

As for your new org:
With this name and the hard cut already done, I wonder if this isnt also the change to do some other sure welcomed changes.

• License: Is it possible to change the license to MIT moving forward? I imagine it probably isnt
• "php": ">=5.4.0" is a bit bongers given the current PHP EOL timeline, I wonder if we couldnt just go 7.4+ from now on making also contributing easier, verifying with GA etc.

People have to switch over in a new minor or possibly major anyway, so just some thoughts regarding a cleaned up release that is future proof while still maintaining a bit of BC.

[dereuromark]

Also free free to make a PR to switch out the repo on the PHP awesome list: https://github.com/php-collective/awesome-php

[jrfnl]

@dereuromark

Thank you for the initiative It sure sucks to have to redo all that as this is quite the hard cut here. Especially also for consumers or custom sniffer packages depending on the sniffer repo (as I do).

... which is exactly why I didn't think a plain abandon would be a realistic scenario. It's not as if I didn't have enough on my plate already, but this feels like one of those "too big to fail" projects, so something needed to be done. Though I very much hope people will support this move and we'll see more regular contributors to the project (instead of drive-by contributors) as it shouldn't all depend on me.

As for your new org: With this name and the hard cut already done, I wonder if this isnt also the change to do some other sure welcomed changes.

* License: Is it possible to change the license to MIT moving forward? I imagine it probably isnt

Changing the license is not really an option. It would need permission from all past contributors, so I don't think that's realistic. I also don't really think there's anything wrong with the BSD3 license.

* `"php": ">=5.4.0"` is a bit bongers given the current PHP EOL timeline, I wonder if we couldnt just go 7.4+ from now on making also contributing easier, verifying with GA etc.

Agreed. PHPCS 4.0 was already announced to have a PHP 7.2 minimum and I think I'll stick to that for the time being.
Having said that, I think more regular releases will also mean more regular major releases, so (depending on time available etc) I imagine 5.0 could have an 8.0 minimum and come out in a year and half or so.

I will share posts with rough roadmap outlines and such once things quieten down a bit. First priority is getting 3.8.0 releeased.

[anomiex]

Thank you for all the work you do, @jrfnl!

Should I copy the few open issues and PRs I had filed from the old repo, or should I hold off until you've done 3.8.0 and gotten other things more figured out?

[jrfnl]

Should I copy the few open issues and PRs I had filed from the old repo, or should I hold off until you've done 3.8.0 and gotten other things more figured out?

@anomiex Feel free to re-file your open issues/PRs in this repo. They won't go into the 3.8.0 release (only what I know is stable and ready for merge will), but I was going to ping you about them anyway ;-)

[dereuromark]

That said:
I thought about making an awesome page for code sniffers and fixers alone, what do you think?
Does it make sense to track all the different packages and addons, also with all those different emphasis.
https://github.com/php-collective/awesome-php-sniffers
Maybe we could use the current momentum to also complete this list and create awareness of this main tool.

[jrfnl]

That said: I thought about making an awesome page for code sniffers and fixers alone, what do you think? Does it make sense to track all the different packages and addons, also with all those different emphasis. https://github.com/php-collective/awesome-php-sniffers Maybe we could use the current momentum to also complete this list and create awareness of this main tool.

@dereuromark Sounds related to #7 and some other ideas I've had for a while, but never had the time to execute.

I was thinking more along the lines of a proper website for PHPCS with:

• A searchable directory of sniffs from all the big/generic (non-company specific) standards.
• Blog posts about certain PHPCS features,
• Ruleset best practices tutorials/blog posts.
• Sniff writing tutorials/blog posts.
• Reference material, like which tokens are available as of which PHPCS versions.
• Possibly a phpDocumentor generated sub-site for the (non-sniff) classes, sort of similar to the docs which used to be generated on a release on the PEAR website.

In my mind, this would be a GH Pages website on the phpcodesniffer.com domain, with things like the sniff directory automatically updated via GH actions workflows on releases of the standards which are included. Similar for the non-sniff class docs.

I already created a repo for it years ago, just never got round to filling it (though I do have some bits and pieces locally).

If you are interested in collaborating on this, I'd welcome that! Maybe we could start with opening issues about ideas for such a site in the repo ?

Not everything needs to be available from the start, we can take the time to start small and flesh the website out when time permits.

[williamdes]

Possibly a phpDocumentor generated sub-site for the (non-sniff) classes, sort of similar to the docs which used to be generated on a release on the PEAR website.

Did you hear about: https://github.com/code-lts/doctum#readme

[forrest79]

Hi, I don't want to start a new issue and I have just one quick question - is there some plan to split packages - one for PHPCS and one package for every standard? So one can require only standards that are needed in his stack and every standard can be upgraded independently on the whole PHPCS?

[jrfnl]

@forrest79 Not at this time. Having said that, I don't intend to accept new standards in the main repo anymore and intend to create those in separate repos which will contain a limited set of related standards.

In a way, PHPCSExtra can be seen in that light, though that was originally a way to release sniffs which use PHPCSUtils and therefore couldn't be pulled to this repo, but for the future, think a PHPCSDocs package which will contain a PSR5 and a PSR19 standards (if ever I find enough time to get it done).

[forrest79]

OK, I understand. Thank you for a quick response,