A few travis config observations about harmony HOT 11 CLOSED

1. Done
2. Done
3. It was a really big oversight from me, thanks for pointing this out.. I thought that dev dependencies are also installed recursively that's why I didn't want to pollute the end users' vendor directory with Harmony's dev dependencies.
4. That's a really nice solution indeed, I updated my config.

Please review this commit if you have time: 6994508

from harmony.

Thanks for these recommendations, I'll definitely have a deeper look at them during the weekend. By the way, the entire Travis config was copied from Zend Diactoros :D So now, it's time to rethink things!

from harmony.

Added a few comments

from harmony.

I would suggest adding an environment to the matrix which tests dependencies against the lowest versions as well: https://github.com/php-http/httplug/blob/master/.travis.yml#L28

The rationale behind is to make sure that the given lowest version constraints are actually supported (composer always installs the latest possible versions)

from harmony.

When I was reading this suggestion, I realized that as I only run unit tests (and not integration tests), I shouldn't require Diactoros and FastRoute as dev dependencies at all, I should mock them instead in the tests. So I'll probably be able to remove them from the composer.json.

from harmony.

Well, there are two things to consider: One is that during development you might actually want to do functional testing which requires an implementation. The other is that (as you said) in unit tests you should mock the external dependencies. (However, in our case the external dependencies are (kind of) Value Objects in which case it is not always so obvious).

Another reason why you might want to install actual implementations as dev dependencies: you can add virtual packages as requirements (eg. psr/http-message-implementation) which requires a package that provides that virtual package, even in dev.

from harmony.

Requiring a psr/http-message-implementation dependency really makes sense! I've added it in this commit (f460540).

Furthermore, it came to my mind that Harmony provides a really dump container-interop implementation so I reflected this in the following commit: 6d95d23

from harmony.

Requiring a psr/http-message-implementation dependency really makes sense!

👍

Harmony provides a really dump

What does it mean? Dummy? Dumb?

If it is not actually meant to be used then maybe providing the package is not so good idea. Just my 2 cents.

from harmony.

I mean dumb :D

But it is fully functional and it can be used if your controllers don't have any dependencies and you don't want a more sophisticated container-interop compliant DIC.

from harmony.

I see. Well, if it actually makes sense to reuse it, then of course it makes sense to provide that package.

from harmony.

I am closing the issue now, but feel free to reopen it if you think something is missing.

from harmony.