New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: new round of changing the "type" suggestion PRs ? #155
Comments
That is correct several MRs, were opened using the template from our wiki. The last time, there were 2 other packages that did the same as this one. Currently we seem to be the only one? The wiki also has a page that lists Known-compatible-PHP_CodeSniffer-standards. We might want to change that to only list well-known packages and link to the packagist type for the rest. Referring to well-known names in the template/MRs also probably won't hurt. After we've updated the template, we could make a long-list and start opening MRs. Although we might want to wait until after we move organisations 🤔 |
Note to self: Organisation move has been completed! Time to make that long list, yo. |
Making the long-list wouldn't have to wait, but I agree sending should be put on hold until we've got everything in order. |
Follow-up question: Is this issue still relevant? Especially since this org is now the official home of PHPCS development. If still relevant, I could have a stab at preparing the long list. |
As this ticket is two years old, I can imagine that the first step should be to update the list in the original issue, i.e. see if and if so, which other Maybe @rodrigoprimo could help with that ? |
@jrfnl, I'd be happy to help, but I'm not sure I understand everything that needs to be done. I can check the list you provided in the original issue and see if the number of packages for each of the types changed.
I'm not sure how I would figure out which other |
@rodrigoprimo Thank you!
The goal of this exercise is to improve the PHPCS end-user experience by making sure that external PHPCS standards use the External standards do not have to External standards which do If I remember correctly, I did a variety of searches on Packagist to find
For the types I found which looked to contain external standards, I would open the page for each of those packages and also click-through to the actual repo to figure out the status, where "status" was a combination of:
Does this help to get you started ? Oh, and no need to let yourself be limited by what I did, feel free to get creative ;-) |
Thanks a lot, @jrfnl. That is super helpful. I will look into this in the next few days. |
At this moment, the plugin very deliberately only registers packages with the
phpcodesniffer-standard
type set in theircomposer.json
file with PHP_CodeSniffer (providing aruleset.xml
file can be found in the package).There are currently 307 packages registered in Packagist which use the
phpcodesniffer-standard
type.When going through Packagist, however, there are a number of other "types" typically used for PHPCS standards:
coding-standard
: 24 packagesphpcs-standard
: 7 packages - most seem to be abandoned, but all seem to be expect to be used with the Goatherd PHPCS Installer (Composer plugin) which seems to have been abandoned 7 years agocoding-standards
: 1 package - is actually a CS-Fixer packagephpcs-coding-standard
: 1 package - PHPCS 1.x package and looks abandonedphpcs-coding-standards
: . package - candidate to suggest changing the typephpcs-ruleset
: 1 package - candidate to suggest changing the typecodesniffer-standard
: 1 package - candidate to suggest changing the typeIf I remember correctly, a couple of years ago, a round of PRs was send in to repos for external PHPCS standards to update the Composer "type". Would it be an idea to selectively do so again ?
The text was updated successfully, but these errors were encountered: