The Future of PHP_CodeSniffer
jrfnl opened this issue · comments
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
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 channels 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.
/cc @kukulich @wimg @weierophinney @GaryJones @dingo-d @klausi @photodude @Potherca @webimpress @fredden @michalbundyra @sirbrillig @othercorey @greg0ire @dereuromark @umherirrender @stronk7 @Ocramius
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.
Would it be possible to mark the package as abandoned from Packagist's side to suggest phpcsstandards/php_codesniffer instead?
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.
Would it be possible to mark the package as abandoned from Packagist's side to suggest
phpcsstandards/php_codesnifferinstead?
@theofidry See PR #3933
As @jrfnl already created a PR to update the phive alias for easy installation, I just wanted to let everybody here know we - as the phar.io / phive team - will be merging the change as soon as there's an official confirmation, for instance by a comment here by @gsherwood or via approval on the PR on our site (phar-io/phar.io#143).
Thank you for the detailed explanation, very much appreciated.
@jrfnl I think it's possible to migrate all issues using this script https://gist.github.com/slaFFik/e1593c6597f11bb7c4dd5122f7f04de9
You will need to recreate all the labels manually to assign labels in a new place properly and automatically.
But issues will be removed in the current repo, so maybe adjustments are needed to just "create", not "transfer" (docs).
Thank you for the detailed explanation, very much appreciated.
@jrfnl I think it's possible to migrate all issues using this script https://gist.github.com/slaFFik/e1593c6597f11bb7c4dd5122f7f04de9
You will need to recreate all the labels manually to assign labels in a new place properly and automatically. But issues will be removed in the current repo, so maybe adjustments are needed to just "create", not "transfer" (docs).
@slaFFik Thanks for that suggestion. Looks useful, though I don't think I will use it. While it is nice to have the issue history, it is also nice to start with a clean slate. There are lots of open issues here and quite some are stale and possibly no longer relevant, so I think I'll leave it up to the original reporters to transfer over their own issues if still relevant. (and I'll nudge in various open issues/PRs when I think the issue definitely is still relevant).
@jrfnl thank you for your transparency and your effort, already.
Though, I hope the whole affair could be resolved differently, I can relate to your situation, as I was in a similar one with PHP Depend & PHP Mess Detector myself four years ago.
As for the funding, I can recommend you the following:
- Setup sponsoring on GitHub for the newly created organistion
- Setup an account on Open Collective for the newly created organistion
- Talk to the people from @tidelift, I'm sure the continued maintenance for PHPCS is of quite some value for their enterprise customers. I'll can provide you with an e-mail contact, if necessary.
Further options for funding I know of (not tested myself, though):
- thanks.dev
- StackAid
- Liberapay fork of Gratipay (nèe Gittip)
- Kivach
Also, as a little jump start, I will nominate you for my emlpoyer's symbolic ~50 USD one time FOSS donation. We wanted to donate to Greg in the past but that never panned out.
As for the issues, as long as the old repos keeps available, I also recommend you to do a fresh start in the new repo.
One last thing:
Back in 2019, instead of trying to maintain those projects myself, I contacted all of the most active contributors of the two projects and asked them if they wanted to join a new maintainer team.
Quite a few joined and some of them stayed and maintain the prroject to this day.
All the best from Switzerland.
Thank you very much for keeping this project alive, @jrfnl!
I don't want to step on anyone's feet here, so I'll ask here first:
Are there any plans to update wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer and phpcompatibility/phpcompatibility-wp to account for the move?
Thank you for all the effort you put into this, @jrfnl! Happy to be contributor nr. 2 - someone beat me on the way :-(
@jrfnl I just wanted to chime in, and say that you’re an absolute star. Thank you for everything you do for this community, and your continued transparency around it.
I don't want to step on anyone's feet here, so I'll ask here first:
Are there any plans to update
wp-coding-standards/wpcs,dealerdirect/phpcodesniffer-composer-installerandphpcompatibility/phpcompatibility-wpto account for the move?
@aldavigdis I have branches ready to update all of those (basically for all external standards I'm actively involved in). Still currently working through my "post announce" action list (which is long) while also responding to all the messages coming in.
Still, there are plenty more external standards for which I don't have PRs ready, so any of those you could help, would be great ;-)
@jrfnl my CTO just alerted me to this thread. Thank you for your contributions. I'm going to move my one or two unmerged PRs from last year that you helped me review into your repository and convert my company's repositories to use the fork
Aside from that I'm committed to helping you get funding as well
Thank you for taking charge and thank you for being so committed to helping all of us that have committed PRs even when you didn't have merge/commit access.
You are a superstar. Wish this would have happened sooner but glad it happened at all.
throwing it out there
what about a phpcs2, that... is not......... any of the old code lol. its. got flavour. plus with that word "ownership" being thrown around.
Thank you very much @gsherwood for all of your efforts with PHP_CodeSniffer. And thank you @jrfnl not only for this message but, most importantly, for opening this discussion in maintaining such an amazing tool.
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.
On GitHub, the wiki is a repository with Markdown files. It should be pretty easy to clone, add a remote, and push.
On GitHub, the wiki is a repository with Markdown files. It should be pretty easy to clone, add a remote, and push.
@benjifisher Already done.
This is awesome, thanks @jrfnl for taking continuous care and keeping focus on progress 🙏
Thank you both of you, @gsherwood and @jrfnl for your time spent on this project. Much appreciated 🍻. Pity that project couldn't be transferred, would make the transition smoother.
PS. Is it only me who sees PHP CSS (tandards) there 😆? Vendor name for Composer could be better (php-coding-standards), but maybe not many purists like me out there 🤪.
I just want to thank you for keeping it up.
And please take it easy. Don't get yourself burned out in the process.
It's important to take breaks.
❤️
@jrfnl if you want help on maintain i'll be happy to help.
Thanks for all your effort people!
Long live to Open Source.
@jrfnl if you want help on maintain i'll be happy to help. Thanks for all your effort guys! Long live to Open Source.
@leodisarli Always happy with help. The CONTRIBUTING info has been greatly expanded in the new repo to get contributors started.
People who become regular contributors with consistently good contributions are welcome to become co-maintainers.
P.S.: no "guys" here.
@jrfnl if you want help on maintain i'll be happy to help. Thanks for all your effort guys! Long live to Open Source.
@leodisarli Always happy with help. The CONTRIBUTING info has been greatly expanded in the new repo to get contributors started.
People who become regular contributors with consistently good contributions are welcome to become co-maintainers.
P.S.: no "guys" here.
Sorry, already corrected myself. Let's go.
@jrfnl I think we can happily approve a new account for you on https://pear.php.net/account-request.php so new releases can still be published through the pear installer.
@jrfnl I think we can happily approve a new account for you on https://pear.php.net/account-request.php so new releases can still be published through the pear installer.
@kenguest I appreciate the offer, but as PEAR support was going to be dropped in v 4.0 anyway and I don't even have SVN installed anymore, I think what with all the other moving parts already on my plate, I can do without the extra headache 😏
It's not as if I've heard anyone seriously complaining about PEAR support being dropped so far...
Hey, thank you for continuing this. If I can help in any way I'd be willing to contribute so if you need an extra drop me a line!
@costeaalex Quality contributions are always welcome. Have a look at the CONTRIBUTING guide to get you started.
why not just fund J to buy it? if they claim code ownership (meaning they don’t want to give it for free), yet they don't want to maintain it, I'm guessing some $ would help move it along - and rightfully so since SquizLabs has surely put in their blood, sweat, and tears into this for years. Is there some GoFundMe amount they might be interested in, @jrfnl?
@cliffordp I'm not the right person to ask about amounts as I have no connection with Squizlabs (other than Greg).
Having said that, I think it would be far more prudent to fund the future of the project (you can find links to do so in the announcement post above) instead of throwing money at the past.
Thanks for the write-up @jrfnl and for making sure the project continues on.
Yes, it's time for me to stop maintaining PHP_CodeSniffer after more than 17 years working on the project. Life is very different these days and I don't have the time I once had. I tried to devote some time each week to the project, then tried each month, then realised I wanted to spend the little free time I have with my family instead of in front of my machine.
I've worked with a few major contributors over the years, but @jrfnl has by far been the most impactful and has stuck around the longest, so I'm delighted that she is taking the codebase and continuing to improve it and I encourage everyone to support her work.
For those asking, no I am not going to transfer ownership of the Github project itself. I've never received any financial support for this the work I've done on this project and no amount now will impact any decision, but thank you for asking. If the packagist identifier could be remapped I would, so someone can please tell me if that is possible. Otherwise I will mark the package as replaced by https://packagist.org/packages/phpcsstandards/php_codesniffer
Thanks to everyone who has used PHP_CodeSniffer over the years, and especially those who have contributed to it directly. Your help was always very greatly appreciated.
@gsherwood Thanks for the fantastic open source software you created, software that many, including myself, have built on top of to create even more open source software. Without your commitment over the past 17 years none of that software would have existed. You should be proud of your accomplishment and I'm sure you're very happy to see the project moving forward and upwards to newer highs in the capable hands of @jrfnl
Thanks again and cherish every moment with your family ♥
If the packagist identifier could be remapped I would, so someone can please tell me if that is possible.
@Seldaek Is that a possibility ?
@jrfnl and @gsherwood All that would need to happen is for the admin of squizlabs/php_codesniffer over at packagist.org to change the Git address to the new repo.
Then push a new minor version tag on the new repo, and everyone's composer will automagically pull in the new build from the new git repo.
The exact URL would be https://packagist.org/packages/squizlabs/php_codesnipper/edit?
(It goes without saying, but for completeness: Every...single...tag in the old repo must be in the new repo location, with the same SHAs.)
Composer and Packagist were built for scenarios exactly like this - moving underlying repo around, without changing the package name. So yeah, basically it's only the matter of changing repo URL on Packagist's side, BUT @jrfnl's repo should revert to original package name here in order to work, which may be troublesome because new package name already was appointed and people made the switch already 🤔. IMHO if @gsherwood is open for that, this would be better move anyway - keeping existing package name would prevent more migration work for many more projects, and download stats would be stored in the same place as before.
New repo technically is not a fork of original repo, but was created with the same history, and tags are exactly the same (including SHAs):
That means there won't be any problems with backward compatibility. Most probably there's no even need to release new version - after changing repo's URL on Packagist and doing composer update on clients' side the same tag can be used but with changed URL.
Right I'd say keep the package name and just point the package to the new git repo on packagist if that's an option @gsherwood can live with. It keeps this repository at its original location, but allows a smooth upgrade path for all users to the new git repo. And if you do it that way it would be best to also add @jrfnl as maintainer on packagist.org - I can help and do any or all of that myself if needed but I'd like to hear the OK from Greg :)
Otherwise if the above isn't acceptable, mark it abandoned and point to the new package (i.e. merge #3933), that is the next best option but it will require all users to update their require statements (some may have done so already, but this could be undone more easily than everyone else having to update I imagine).
Indeed. Thanks @Seldaek @hopeseekr @Wirone for your responses.
I would very much prefer that situation as it will make the change much smoother for end-users, though I would insist on being added as an admin on Packagist, otherwise things would still be outside of my control in the future, which I don't think would be good.
- The PHPCSStandards repo is a fork, so all tags prior to now are available with the same SHA.
- I also re-released all tags from 2.0.0 - 3.7.2 (mostly for the PHARS to be available via the releases).
It's trivial for me to change the Composer name back in the PHPCSStandards repo and I'd be very happy to do so.
Yes, for those few users who didn't heed my warning to wait with switching until there had been a release, those would need to switch back, but that's a much smaller number than all the Composer users having to switch and it will prevent a world of potential issues with vendor/bin files if people would change the package name, but would not update to the latest tag, so let's.
I would still suggest for this repo to be marked as abandoned, but only on a GitHub repo level and with a note at the top of the README, but not in the composer.json file.
FYI: I've tried to find all repos which already had open/merged PRs switching the Composer package name and left notes on those PRs. Similar for open issues regarding this.
No doubt I will not have found every one of them, but this should hopefully spread the word sufficiently.
Thank you for doing that, Juliette, and for all of your hard work on this project.
FYI: The change on Packagist has gone through and the squizlabs/php_codesniffer package will now update from the https://github.com/PHPCSStandards/PHP_CodeSniffer repo. Thank you @Seldaek !
And... you should now all be able to enjoy the 3.8.0 release, which has just gone out.
I hope it went well as I guestimated a release checklist. Please let me know if I missed something or if something isn't working as expected.
TL;DR: This repo is being abandoned.
So far the project is not archived yet and doesn't have any notice about state of the development.
What happened was a chance to abandon this project. I don't understand why PHP needs 2 coding styles fixers? Code Sniffer has a terrible DX (so it's terrible tool overall because it's only a developer tool). The PHP-CS-Fixer project is much better.
@javaDeveloperKid They are different tools with different capabilities and a different eco-system. PHP-CS-Fixer is great if all you want/need are code style issues fixed. PHPCS can do a lot more than that though.
I'm glad you are happy with PHP-CS-Fixer, but please show some respect to all the other people making different choices for their projects.
@javaDeveloperKid as a PHP-CS-Fixer's maintainer I can only say you're wrong and your comment was totally unnecessary. Sniffer has capabilities Fixer won't ever have, like PHPCompatibility extension. It's great that Sniffer's development will be continued 👍.
@javaDeveloperKid "I think the demise of Windows Vista was a chance to abandon WIndows. I don't understand why the world needs more than 1 operating system ? Windows Vista was so horrible. Linux is so much better."
@jrfnl @Wirone
Ok, if Sniffer has capabilities Fixer won't ever have then let's still develop them. But why to duplicate and maintain two coding styles fixers for a language at the same time? Maybe Code Sniffer should be a tool providing the capabilities you're talking about but not code style fixing?
Secondly, what I was pointing out was a bad DX of Code Sniffer (comparing to php-cs-fixer), not a set of capabilities difference and this is the part you haven't addressed in you comments.
@wimg Actually your example is not a good one. In general Linux and Windows serve another purpose and aim another group of people.
@javaDeveloperKid first of all it's not a good place for such discussion. I did not address your DX concern because it's a totally subjective thing - I don't have any problems with it. And developing more tools is better for the language, because competition in general is good, it pushes things forward. Why does it bother you? It's not your time and effort.
@javaDeveloperKid You're free to improve the DX of CodeSniffer. Just send pull requests.
Otherwise you're just making comments on the hard and unpaid work of many people who volunteer their free time to create tools that are used by tens of thousands of people around the world.
I don't have any problems with it
You're a php-cs-fixer maintainer and you use another tool? Plus, of course you don't have problems because you maintain a similar tool so you know the know-how of the problem.
Why does it bother you?
It bothers me because when I change a team or company and it uses another coding styles fixer then I have another tool to learn. I understand that different companies/teams can use different e.g. http client - the architecture and/or performance of a client might be different. Filesystem abstraction library - the same, one can decide this implementation and public interface is better for he's needs. But code style fixing tool? This is so generic problem that having more than one tool is just a waste of time - both, the maintainers and end users, as the former spend time do reinvent the wheel while they could join forces and contribute to one project and the latter have to often learn more than one tool.
@wimg
Please don't use the argument about volunteer's hard and unpaid work. I much respect every open source maintainer and contributor, because everyone that devotes he's free time for unpaid work deserves respect. However this should not mean one can't make a comment that undermines the sense of existence of the library. Sharing opinion is important and valuable and may open a new POV even if someone does not like/agree with this opinion.
However this should not mean one can't make a comment that undermines the sense of existence of the library. Sharing opinion is important and valuable and may open a new POV even if someone does not like/agree with this opinion.
@javaDeveloperKid If you have nothing constructive to add, it's better to stay silent and your comments are not leading to a constructive conversation, but are derivative and dismissive.
It bothers me because when I change a team or company and it uses another coding styles fixer then I have another tool to learn.
If learning new tools bothers you, you may be in the wrong line of work...
I'm going to hide the last few comments in this thread now as none of this is constructive or even remotely relevant to the topic of this issue.
Sharing opinion is important and valuable
When the opinion you're sharing is "I don't see the need for this tool" or "I like a different tool", it's not helping anybody. The folks developing this tool and using it clearly find a need for it, and have a stated preference for using it (either personal, or as required by a project or org they work on or for).
phpcs pre-dates php-cs-fixer by more than a decade. Additionally, the two have very different mechanisms for extension, sharing extensions, and how they operate. php-cs-fixer grew from the Symfony ecosystem, focuses on the standards of that ecosystem, and is highly optimized towards fixing CS issues; if it can't fix it, the rule cannot be used. phpcs splits identifying and fixing issues as responsibilities, recognizing that some issues cannot be automatically fixed, but may need somebody to intervene - whether that's through refactoring, or skipping a rule at that location. This ability allows creation of tools like phpcompat.
Personally, I've preferred phpcs to php-cs-fixer as I've found it easier to configure and easier to share rules. I will NOT, however, say it's objectively worse or better - they're just different.
There's room for more than one approach here. Saying otherwise is discounting entire communities of developers.
@jrfnl
It's important to remember that you're not a perfectly valid person to judge whether such comments with criticism are constructive or not as you're a beneficiary of this project when it will receive sponsoring. It's obvious that most of the developers would like to work on an open source project for money than in some company.
If learning new tools bothers you
Maybe we differently understand what learning new tools means. I don't learn for a sake of learning. I love learning new tools when there is a real need, when they solve a real problem. For such a generic problem like coding styles I don't want to have several tools. I need just one, have code fixed and focus on real technical or business problems. A day has only 24 hours and we should focus on real problems, not how another coding styles fixing tools works and how to use it.
P.S. Btw. I wish you the very best. Don't take it personal. I just think that many people would say that there could be one tool for fixing coding styles.
This part of the comment was marked as off-topic by its author
Okay, so I just read the off-topic thread... That was weird O_o.Anyway, more on topic...
I was wondering if something needs to be done with the discussions at https://github.com/squizlabs/PHP_CodeSniffer/discussions
Has someone already looked at them and/or decided if there are things that are worth moving/copying to https://github.com/PHPCSStandards/PHP_CodeSniffer/discussions ?
I was wondering if something needs to be done with the discussions at https://github.com/squizlabs/PHP_CodeSniffer/discussions
Has someone already looked at them and/or decided if there are things that are worth moving/copying to https://github.com/PHPCSStandards/PHP_CodeSniffer/discussions ?
That's one thing I haven't looked into yet. Opinions welcome.
FYI: For open PRs and issues I still intend to leave comments on the viable ones over the next few weeks to invite people to move them over. Just haven't got round to it yet.
@squizlabs: It is possible to add changes from PEAR?
It will be nice to have all changes in upstream...
And where will be the good place?
Thanks in advance.
cc: @CloCkWeRX, @pear team.
@squizlabs: It is possible to add changes from PEAR?
* [master...pear:PHP_CodeSniffer:master](https://github.com/squizlabs/PHP_CodeSniffer/compare/master...pear:PHP_CodeSniffer:master)It will be nice to have all changes in upstream...
And where will be the good place?
Thanks in advance.
cc: @CloCkWeRX, @pear team.
@Neustradamus Looks like those changes are specific to PEAR and not relevant to the actual project itself. I don't think any action is needed on this.
Could you add a note to the README of the squizlabs project? At the moment, you have to view the issue page to see the post about the new project.