squizlabs / PHP_CodeSniffer

PHP_CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards.
BSD 3-Clause "New" or "Revised" License
10.66k stars 1.48k forks source link

The Future of PHP_CodeSniffer #3932

Open jrfnl opened 9 months ago

jrfnl commented 9 months ago

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.

image

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:

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

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 channels through which this project can receive funds:

If you support me in this, you can indicate this via a :+1: 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

weierophinney commented 8 months ago

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.

javaDeveloperKid commented 8 months ago

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

Potherca commented 8 months ago
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 ?

jrfnl commented 8 months ago

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.

Neustradamus commented 7 months ago

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

jrfnl commented 7 months ago

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

mbomb007 commented 7 months ago

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.

jrfnl commented 7 months ago

@mbomb007 There is a PR open for that: https://github.com/squizlabs/PHP_CodeSniffer/pull/3933