travis.yml
, and of course if you have any question or want to do a call I'll be free (not this weekend though)
Yep, so basically when you bundle a PHAR, your dependencies are not isolated. So for example PHPUnit
is using symfony/yaml
. So it PHPunit is using symfony/yaml 3.1
and your library is using symfony/yaml 2.8
, because it's a PHAR you won't notice any dependencies conflict, but when you'll run your test via the PHAR the symfony/yaml
used will be symfony/yaml 3.1
so it can break your code, go unoticed or cause some weird bug. It's more a PHP problem than PHARs are the only way to solve this issue would be to rename namespaces, which can break some code. Say for example if you do:
$class = $dummy->getFooClass();
$x = new $class();
This would break. So that's why dependencies in PHARs are not completely isolated. So whenever you want to use a tool (even if it's a dedicated application), as soon as it executes your code, it should be a dev dependency and not a PHAR or a dependency installed via another package.json
like it would happen with https://github.com/bamarni/composer-bin-plugin.