Gert de Pagter

if you specify the `run` command, then it does work without the `=`. So this will work: ```bash $ vendor/bin/infection run -c file ``` This is a limitation of using...

PHPStan can infer the types from private properties, but not from protected or public ones. So whichever way we go, we do need to keep them on those properties.

@theofidry I agree that its really not ideal preformance wise. But depending on your use case that should not really matter. I don't think you would run it like this...

I would use it to just run php unit again, since `@covers` annotations can mess with the results sometimes, especially for integration tests. And also for tests like behat. >Besides...

Using psalm and phpstan with the code generated by infection will generate errors (killed mutatants) when it shouldn't. At least with most configurations. Most of these will be due to...

Great idea. One thing i am concerned about is how we can deal with our scoped phar. This means we have a different class to extend when running with the...

My issue is not with the phar itself. We use php-scoper to prefix all namespaces in the phar, since it needs to be auto-loaded. This means that the class to...

> When code coverage is provided, make use of it to know which tests to execute and in what order (already done to a certain extend I believe?) I think...

I like this feature in tools like psalm/phpstan etc. However, i don't think it is a good fit for infection. For static analysis tools, its all or nothing, the checks...

> I had this idea for some time. For one because I wanted a tool which I could use in place of `PHPUnit` executable to do mutation testing against a...