[PROPOSAL] More interoperability / Better workflow

[abellion]

Laravel is absolutely awesome and I love his agility but there is some leaks :

• Some of his components have a strong attachement to some others that are directly related to Laravel framework specific code.
• Some components uses methods that are not in the contract (component interface).
• All of the changes are not reported into the changelog.

1st suggestion - component structure :

It wouldn't be better to define a folder structure for each component and to provide unit tests at a component level ?

src/
tests/
.gitignore
composer.json
README.md
CHANGELOG.md

Maybe following this standard : https://github.com/php-pds/skeleton

2nd suggestion - remove services providers from components :

What if I want to use one of the component but without Laravel ? I think a better solution would to put each bridges (service providers) between the standalone packages and the Laravel framework inside the foundation component.

By the way, is this foundation component make sense ? I mean, is it really a component or a sort of connector between components (that make the framework thus).

Conclusion :

With this philosophy the framework repo could looks like this :

src/
    foundation/
    components/
tests/
.gitignore
composer.json
README.md
CHANGELOG.md

At this level the unit tests would test the foundation code, which serve as a connector between the components.

These ideas came to me because I used to work with the Symfony framework (https://github.com/symfony/symfony) and it's exactly the strategy that they adopt and I find it very good ; what do you think ? Some inspiration came from Vue.js too.

Last thought : with this kind of structure / way of work, which would be more elastic and progressive, Laravel could be used as a micro framework as well as a complete and full featured one.

[abellion]

383 Goes in the "Better workflow" of this proposal.

[abellion]

I found a standard skeleton for PHP packages that seems good : https://github.com/php-pds/skeleton

[taylorotwell]

Laravel is a full-stack framework.

[abellion]

So what's the point of making separate components if they cannot be used as such ?

[Garbee]

I'm not sure what exactly is wrong now. For example you want service providers in their own package, but they don't affect anything unless you call it. So, it hurts nothing being there.

Further, I'm not sure how the structure of each component matters. Could you elaborate on exactly what that would provide and allow for?

Components can be pulled in directly, they may just rely on other components as well. Such is life with the way Laravel is built. There are plenty of other options for the functionality if you have major issues with this.

[abellion]

It's just about separation of concerns.

For example I wouldn't feel confident using the mail component because there is no Readme, no Changelog neither tests. Also he requires the illuminate container to grab some instances of some services that are not listed in the dependency file. So in any way it wouldn't work for standalone usage which is too bad because it can bring a good value to a lot of PHP projects that don't use Laravel. And sadly it seems that a lot of components have that kind of issues.

In an other hand I totally understand that Laravel needs connection between components, like Taylor said Laravel is a full-stack framework. This is why I suggested to make some bridges to connect them all together. This way components would be usable anywhere and the full stack framework would stay full stack.

Last point on the structure : Readme, Changelog and tests would hang around others PHP files which could be weird, so sorting them would be better.