Code directory name

[florianv]

Shouldn't the code directory called src or library? I mean vendor is kind of reserved for composer.

Let's say you install Joomla's dependencies, they will be installed in that folder, and you cannot ignore them.

So let's say we put src instead.

Then we modify the main composer.json file to contain all joomla-framework packages as dependencies.

The correct flow to run the full tests suite is : install joomla packages via composer, they will be installed in vendor/, use composer autoloader in the test bootstrap (so that all dependencies are autoloaded) and run the tests.

It ensures that all packages dependencies are correctly defined in each composer.json file and installed.

ALL frameworks use this method, and they ignore the vendor folder :

Symfony : https://github.com/symfony/symfony/blob/master/.gitignore Monolog : https://github.com/Seldaek/monolog/blob/master/.gitignore Composer : https://github.com/composer/composer/blob/master/.gitignore

[dongilbert]

Well, this repo isn't where you should be installing from or getting the package code. You should install each package individually as needed. This repo is really just where development happens.

We envision a "joomla-framework-standard" repo that has a basic app structure setup with folder's etc, and then its composer.json brings in all the joomla packages as needed. That way, when starting a new project, you'll simply use:

composer create-project joomla/framework-standard ./project-path

and then you'll have a starting structure to use.

And your comment that all frameworks use this method, you only linked to one actual framework, the other two are packages. However, I did check Laravel and they do it as you describe, with a src folder, and FuelPHP does it that way as well.

So, it may be that we should as well. But I retain my assertion that you shouldn't be cloning and coding from this repo.

[florianv]

I see this repo as the fullstack framework, having a main composer.json file containing all sub-packages joomla-framework-* as dependency.

That way, it's possible to run the full test suite using the flow mentionned above. Because let's say database depends on log, there is a push to log but it could make the database tests failing.

So there is the need to run the full suite.

So it's splitted into x individual packages, and people can grab them independently but you can also use the full stack framework, and that's probably what the future CMS will do.

[ianmacl]

If a push to log makes the database tests fail then are log tests are broken. Unit tests for database ideally shouldn't depend on code other than database, beyond an interface.

We should do integration testing as well, but that, IMO, is something different.

[florianv]

Well, in the case you introduce a B/C break for some reasons. You update the log tests, they run. But the database package (and tests) needs to be updated too. This method will only work if the packages are totally decoupled (which won't be the case tomorrow).

[AmyStephen]

@florianv - If the API changes for the package, then there are other impacts. In many ways, though, breaking these packages apart should make it much easier to clarify the API and know when it changed. But, if there are no API changes, unit testing should work perfectly -- even for proving external use.