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.
We also discussed a bit on monolith repo management. As always there is pros and cons everywhere.
For non-monolithic repositories, i.e. everything is splitted in dedicated repositories:
- pros
- each repo can have its own setup without any risk of affecting the step of another part. For example if you require a weird dependency, you are sure it will only affect this repo and not another one. So you have a better isolation and easier setup regarding that point
- it's easier to seperate things well: if you are on a monolithic repositories, it's easier to mix something that should be Symfony specific for example in something that should not
- cons
- slightly harder to manage as soon have you have a cross-repository change
- harder to apprehend if you are not familiar with the code-base
For monolithic repositories, it's a bit the opposite. However I must say thanks to the composer plugin I had quite a pleasant experience when doing it for alice (https://github.com/nelmio/alice) than for https://github.com/api-platform/core and another library of mine.
The two biggest issues I've seen with monolithic repositories were:
- it's way easier to mix things up. For ApiPlatform for example, it's hard to tell what belongs to the Symfony specific and what's not; everything is supposed to be separated by namespaces (and it is), but it's a bit harder to tell at the functionality levels
- you easily run in dependencies conflict. For a library of mine I had a bridge for Laravel and Symfony, but I couldn't require both as a dev dependency as they would conflict.
To the first problem, my "solution" is to stick a framework bridge in a library to exposing a configuration and registering services to the DIC. Anything past that should be done in a dedicated bundle/provider/etc.
To the second the composer plugin made it extremely easy. For example for alice for the symfony bridge, thanks to the plugin I only had to do:
$ composer bin symfony require symfony/framework-bundle
$ composer bin symfony require nelmio/alice:dev-master # you have to include the library itself still if you want to test it against your libraryAnd then for testing the Symfony bridge of alice, I just have to use the vendor-bin/symfony/vendor/autoload.php instead of the default vendor/autoload.php one and play with PHPUnit groups to test only what I want. So it allows me to easily achieve a certain level of isolation without requiring to make the bridges in dedicated repositories.
