First thoughts about a roadmap for the project

[gmponos]

These are my first thoughts about the package

Version 2

• [ ] Allow to configure PhpMetrics thought files (xml, json, yaml)
• [ ] Bring back the self-update command
• [ ] Apply PSR-2 codestyle. Best by using an automation tool (like codesniffer or php-cs-fixer)
• [ ] Include PhpStan
• [ ] Improve documentation

Version 3

• [ ] Drop support for ~PHP 7~ PHP 5. My initial thought is require 7.2 as min.
• [ ] Apply PSR-12 codestyle.
• [ ] Allow extensions to be registered.
• [ ] Add how many final/abstract/trait exists on the reports.
• [ ] Try to find more metrics to include.

Any feedback or help is welcome.

[niconoe-]

Hi @gmponos I used to work for this project. Thank you for taking care now! I hope I will find more time to join you in the next weeks.

About V2 :

• please continue to allow configuration from arguments on CLI also as having many configuration files stored for a project only for QA can be a little bit annoying
• the PSR-12 replaces the PSR-2, and is already available in squizlabs phpcs package
• How about delivering PhpMetrics in a docker container via Dockerfiles? I could help a little bit if you’re interested in.

About V3 :

• you probably mean the support of PHP 5, not PHP 7 ;).
• maybe replacing the cyclomatic complexity by the cognitive complexity in the bubble graph generated could be better

Thank you again!

[gmponos]

please continue to allow configuration from arguments on CLI

ofc.

having many configuration files stored for a project only for QA can be a little bit annoying

are you suggesting to have only one config type (like only yaml)?

the PSR-12 replaces the PSR-2, and is already available in squizlabs phpcs package

Thing is that although PSR-12 does not say it explicitly I believe it is more suited to projects that do not have active support of PHP5. For instance PSR-12 enforces visibility on constants. This feature does not exist on PHP 5. So eventually we will need to exclude some rules if we use PSR-12.

That's why I mentioned PSR-2. Maybe for v3.0 we can think of applying PSR-12 instead.. Will add it in the description above.

you probably mean the support of PHP 5

Yes typo there.. fixed it above...

[gmponos]

I have also one question.

Checking the v1 vs v2 I can see that some packages were removed and custom classes were created instead.

May I ask why? I checked the issues https://github.com/phpmetrics/PhpMetrics/issues/220 and https://github.com/phpmetrics/PhpMetrics/pull/221

but I can not see the motivation behind it? What were the problems raised by using the symfony package?

@Halleck45 maybe you could help here?

[Halleck45]

Yes. I've removed plugins in order to make code more stable. Having plugins is a good idea and is useful for final user. Remiving them was not an objective of v2.

Concerning symfony/console, I encoutered lot or bugs and dependencies issues (I whish support old versions of PHP : PhpMetrics is useful for old projects). Also with dependencies the phar archive was really big.

Finally, I think that the Hoa/Ruler (or symfony/ewpression-language) must come back. The --condition-of-failure was very useful.

Thanks for this issue ! 🙂

[Mte90]

If you want to add support for phpcs, just let the developers to set the standard to use. For phpstan is required also often to install custom packages for some integrations in frameworks and so on so a plugin system or a way to enable them in phpmetrics can be helpful.

[gmponos]

@Mte90 I am not sure if we are discussing about the same thing.. I am not thinking about integrating codesniffer and phpstan inside the reports but I am thinking about checking the code of the repo against PhpStan and Codesniffer.

@Halleck45

I whish support old versions of PHP : PhpMetrics is useful for old projects

are you referring to my suggestion about dropping PHP5... yes I believe the same. Also I think it will take a while until we reach dropping support for PHP 5. There are many things to do until then..

until then let's see how this will go... :)

[Mte90]

uuuhhh got it, my fault.

[gmponos]

Never the less if we ever make it possible for the developers to register their own extensions/modules then modules like phpstan or codesniffer could be interesting...