This goal of this thread is to discuss the internal/external changes we want to address for a 2.0. Let us put the bar high and go even more opinionated concerning rules/preferences.
A board has been created for following the progress https://github.com/nunomaduro/phpinsights/projects/1
I think we should consider this #254 also.
@olivernybroe Can you add that to the list? are you able to edit my comment?
I've started tinkering with running the analysis in parallel. Would this be something you guys would want to have for 2.0?
@MrMadClown Sure that would really be a nice feature for v2.0. I would be up for merging that in v2.0
@MrMadClown did you study the parallel stuff?
How should we proceed with stuff that is V2 and stuff that is fixes for V1?
I suggest using master branch for V2 and then create a branch named 1.x, which is for V1 stuff.
@olivernybroe Agree. Let's do it.
For info, soon I will start to deprecate all the Symfony 4 related stuff. And we will target php 7.4. What do you think?
@nunomaduro Agreed.
We already sorta require php 7.3, so I think it's a good idea for v2, to target php 7.4 and possibly also only Laravel 7 and up. I would be fine with dropping Symfony 4, @Jibbarth do you have any say against this?
I'm :+1: to move forward.
But, from an enterprise point of view, lot of projects can still be targetting sf4.4 (as it's LTS).
Regarding changelog for main SF component, I didn't see any big feature that force us to drop SF4.4 for them (console and finder).
For Finder, upgrading to 4.4 will allow us to use ignoreVCSIgnored.
So, let's upgrade to php7.4 and SF5 for v2, but I think we should keep SF4 and php7.2 on v1.
To upgrade to php7.4, it could be interesting to use Rector to help us to use private typed properties :raised_hands:
We should also not forget, as soon as we use master branch for v2 stuff, to add a branch-alias on 2.0-dev for dev-master :wink:
:thinking: And maybe also we should add a branch in Github PR template to help user to know which branch they have to target ?
Does it make sense to consider offering a GitHub action so that we dont even need to do composer require on our projects?
@deleugpn There is an unofficial one https://github.com/stefanzweifel/phpinsights-action and a formatter for github-action
And I am working on a more advanced one with badges and so on.
@olivernybroe I've looked into the one you linked. It runs composer install on our own project. What I'm asking is about a standalone version of phpinsights as GitHub Action. Not running composer install on my own project means I don't have to deal with my private repositories and secrets, etc.
@deleugpn Alright, sorry, I get your now :)
The GitHub action I am working on creating right now actually works this way. It's still very much in development, as the point of it is to create a GitHub review instead.
You can try out what I have in it so far if you want to https://github.com/worksome/phpinsights-app
Hey @nunomaduro I did tinker some with it back in November but haven't looked at it since.
Are there any plans to release autofixer before 2.0? I'd really like to replace my old setup with phpinsights but it's current limitation of not being able to autofix errors reported by php-cs-fixed or code-sniffer is kinda blocking that.
Also since you're planning to wrap PHPStan, are you planning to wrap Psalm as well?
I don't think we should wrap nothing, before tacking those issues:
Auto fixer (#54)
Error vs. warnings in sniffs (#254)
Reorganize sections/metrics
Parallelization
Bump dependencies
It's important to keep the core sexy, clean, fast and organised.
I agree. Makes sense. But psalm isn't really my main concern. The autofixer is. Do you have plans to release it soon-ish?
I believe is important to ship the auto fixer only with the 2.0. So we don't have to maintain it also on the v1.