Skip to content
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

First thoughts about a roadmap for the project #386

Open
10 tasks
gmponos opened this issue Dec 1, 2019 · 8 comments
Open
10 tasks

First thoughts about a roadmap for the project #386

gmponos opened this issue Dec 1, 2019 · 8 comments

Comments

@gmponos
Copy link
Member

gmponos commented Dec 1, 2019

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-
Copy link
Contributor

niconoe- commented Dec 1, 2019

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
Copy link
Member Author

gmponos commented Dec 1, 2019

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
Copy link
Member Author

gmponos commented Dec 1, 2019

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 #220 and #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
Copy link
Collaborator

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
Copy link
Contributor

Mte90 commented Dec 3, 2019

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
Copy link
Member Author

gmponos commented Dec 3, 2019

@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
Copy link
Contributor

Mte90 commented Dec 3, 2019

uuuhhh got it, my fault.

@gmponos
Copy link
Member Author

gmponos commented Dec 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants