Question: new round of changing the "type" suggestion PRs ?

[jrfnl]

At this moment, the plugin very deliberately only registers packages with the phpcodesniffer-standard type set in their composer.json file with PHP_CodeSniffer (providing a ruleset.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 packages
• phpcs-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 ago
• coding-standards: 1 package - is actually a CS-Fixer package
• phpcs-coding-standard: 1 package - PHPCS 1.x package and looks abandoned
• phpcs-coding-standards: . package - candidate to suggest changing the type
• phpcs-ruleset: 1 package - candidate to suggest changing the type
• codesniffer-standard: 1 package - candidate to suggest changing the type

If 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 ?

[Potherca]

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

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 🤔

[Potherca]

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.

[jrfnl]

@Potherca I'd say: let's wait a little longer until a decision has been taken on #159 as otherwise, we'd have to send in a follow-up PR once that get actioned.

[Potherca]

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.

[Potherca]

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.

[jrfnl]

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 type keywords are currently in use for PHPCS standards and of those, if there are still actively maintained projects in that list which would benefit from a ping.

Maybe @rodrigoprimo could help with that ?

[rodrigoprimo]

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

which other type keywords are currently in use for PHPCS standards

I'm not sure how I would figure out which other type keywords are being used besides the ones you already mentioned in the original issue. Is the idea to search Packagist for keywords like phpcs and so on to see if I find type keywords that are being used by custom code standards that are not included in the original list? Or did I misunderstand your comment, and this is not what you meant?

[jrfnl]

I'd be happy to help

@rodrigoprimo Thank you!

I'm not sure how I would figure out which other type keywords are being used besides the ones you already mentioned in the original issue. Is the idea to search Packagist for keywords like phpcs and so on to see if I find type keywords that are being used by custom code standards that are not included in the original list?

The goal of this exercise is to improve the PHPCS end-user experience by making sure that external PHPCS standards use the type which this plugin supports. This will allow end-users to use this plugin to register the external standard(s) automatically with PHPCS.
As an side-benefit, it will also allow end-users to more easily find other external PHPCS standards which may be interesting to them when searching on Packagist.

External standards do not have to require this plugin for this to work.

External standards which do require[-dev] this plugin must all have the correct type, otherwise things are broken for them already.

If I remember correctly, I did a variety of searches on Packagist to find type keywords being used for external PHPCS standards.

• I used the list of packages using the supported type to find other coding standards related type keywords being used (using "show more" on the type list to see) and then did stand-alone searches with each of those types.
• I also used the tags search to search for packages using keywords like phpcs, phpcbf, php_codesniffer etc. Then would examine the types being used by those packages ("show more") and then do more stand-alone searches with those type keywords.
• I did some spot-checking of packages using the plugin as a non-dev dependency. Those should all have the correct type already.
• I did some spot-checking of packages using the plugin as a dev dependency to see if any of those are external standards which are not using the correct type.
• I did some spot-checking of packages using PHP_CodeSniffer as a non-dev dependency, as those are likely to all be external standards.
  When looking at those packages, I mostly looked for inspiration for other type keywords and other tag searches to use.

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:

• Is the package really an external standard for PHPCS ?
• Does it require another Composer plugin to register standards with PHPCS ? (all others appear to be abandoned by now)
• Is the package still being maintained or has it been abandoned ? (based on repo status/last commit date, not last release date)
• Is the package being used ? (does it have more than 0 downloads/dependents ?)

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 ;-)

[rodrigoprimo]

Does this help to get you started ?

Thanks a lot, @jrfnl. That is super helpful. I will look into this in the next few days.

[rodrigoprimo]

I gave this task a first try. I created a spreadsheet in the link below, updating the information about the packages in the original list and including a few more packages for types that I found.

https://docs.google.com/spreadsheets/d/1Dz_pKLivmcD_pYmV1m4mHYD0MYu1vdYv4H4eN1HtqBA/edit?usp=sharing

To find the new types, I used Packagist API to get the types for all packages (https://packagist.org/packages/list.json?fields[]=type), and then parsed the results to get the unique types and searched that list for a few keywords that occurred to me.

Here are the new types that I found containing PHPCS custom standards:

• php-code-sniffer: 3 packages
• php-standard: 1 package
• phpcs-sniffs: 5 packages - 3 are abandoned

It was nice to see that now there are 419 packages using the phpcodesniffer-standard type compared to 307 packages when this issue was opened.

Here is the full list of Packagist types if anyone wants to take a look as well:
type-list.csv

Please let me know if there is anything else you would like me to do related to this issue.

[Potherca]

FYI: I've updated the MR text template to better reflect the current situation.