Update phpstan to 0.11 && update phpunit to 7.0

[adaamz]

No description provided.

[Majkl578]

Can you please split the changes into two commits - first for PHPUnit and second for PHPStan?

Also for PHPStan:

• please use phpstan.neon.dist + add /phpstan.neon to .gitignore;
• I'd prefer having it in composer.json as dev-dependency, IMO there should be nothing blocking us from doing so;
• if previous is done, also commit composer.lock and remove it from .gitignore.

Thanks.

[adaamz]

I saw that phpstan is installed only in travis.yml in other projects - annotations for example.

I can fix all requested changes ofc.

[Majkl578]

Annotations are not a good example, it's due to historical reasons there too. You can check other projects like DBAL or ORM or Migrations.

[adaamz]

Splitted to 3 commits.
PHPunit update is change only in composer.json, but I added migration from class based to namespace based usage into phpunit commit as well.

[Ocramius]

👍

review comments addressed

[rvitaliy]

@Majkl578 @Ocramius

1. why we commit composer.lock?
2. can i suggest to avoid adding PHPStan as dev-dependency it's not a lib to write code but it's only a tool to execute static analysis of the code.
   if you need a plain PHPStan i suggest to download .phar and execute it in CI.
   if you need a pluggable PHPStan with other plugins i found this solution: https://github.com/bamarni/composer-bin-plugin to include tools as isolated dependencies.

same for other tools like PHP_CodeSniffer, PHP-CS-Fixer, etc...

[Ocramius]

why we commit composer.lock?

Mostly PHPStan and PHPCS checks: feel free to send a patch that does rm composer.lock during the test stages in CI, and we'd need to test against lowest/highest dependencies too.

can i suggest to avoid adding PHPStan as dev-dependency it's not a lib to write code but it's only a tool to execute static analysis of the code.

It's a dev-dependency, and as such it should stay in the locked state that we work with.

if you need a plain PHPStan i suggest to download .phar and execute it in CI.

Please don't do that. We do that sometimes due to cyclic dependencies issues only, but otherwise downloading .phar packages during builds is NOT advisable, since there is no guarantee that the dependencies shipped with the .phar don't collide with the sources and dev dependencies inside this project.

if you need a pluggable PHPStan with other plugins i found this solution: https://github.com/bamarni/composer-bin-plugin to include tools as isolated dependencies.

They should be added to require-dev, exactly like any other dependency used in development environments.