Analysis: determine whether to revive of not

[jrfnl]

The original PHP_CodeSniffer project contained a code consistency analysis website: https://squizlabs.github.io/PHP_CodeSniffer/analysis/

That website hadn't been updated since 2018.

For now, I've removed the site from the gh-pages branch of this repo.

I'm not sure if there is still interest in the analysis website. If so, reviving it under a new (sub)domain would be an option, though the code to generate the site would probably need revision and a critical look as to which projects should be analyzed.

This ticket is intended to measure interest.

Leave a 👍🏻 if you are interested in having this analysis website revived.
Leave a comment if you want to get involved in reviving the analysis website.

Refs:

• c071f81
• d493ab1

[jrfnl]

Also see: squizlabs/PHP_CodeSniffer#3634

[jrfnl]

My current line of thinking about this ticket is as follows (provided there would be enough interest):

• Create a separate repo for the analytics project.
  This repo would effectively create a GH Pages website under a subdomain of the phpcodesniffer.com domain.
• Move the original code used to generate the site to that repo (note: not the website, which was previously also committed).
• Review and update that code, keeping in mind that that project does not need to comply with the PHP 5.4 minimum of the main PHPCS project.
  Things to review the code for:
  • Get it working (again).
  • Check if there are additional metrics which could be added to the report (like PR Add metrics to the PSR2.ControlStructures.SwitchDeclaration sniff #33)
  • Modernize the code.
• Create a workflow to automatically generate the website which can be triggered manually (on a new PHPCS release) and also runs via a monthly/weekly cronjob to keep the site up to date automatically.

Once the initial work is done for this, it should then be (a lot) more straight-forward to keep the site running and up-to-date.

[jrfnl]

Some brain farts related to the analytics website:

• It is not clear what criteria were used historically for which projects to add to the projects list.
  Might be an idea to set criteria for this going forward. I'm currently thinking: the top 500 projects in Packagist.
  This will mean that some projects (projects in the Top 500 which were previously already included) will have history and some don't, but then again, that history could be recreated anyway, if needs be.
• It is not clear what ruleset projects were evaluated against, though I expect this will become clear once someone studies the code of the project.
  It makes sense to evaluate each project against the same ruleset containing only sniffs which record metrics. This makes the projects comparable and it allows for aggregate results.
  At the same time, it might be nice to also allow for additional sniffs a project uses in their own ruleset if those sniffs provide metrics.
• It would be nice - though this could be a separate side-project - to have some insight into the frequency of use for sniffs. This information could be used to inform the PHPCS project for which sniffs could be candidates for removal.
  This could possibly be done by having a complete sniff list of all sniffs in PHPCS and aggregating how often each sniff is encountered in PHPCS rulesets used by those projects in the top 2000 Packagist projects which use PHPCS (via an -e explain).