[Proposal] Make the app directory structure configurable

ChristopheB commented 10 years ago

This proposal suggests to:

remove the hardcoded paths from the framework
allow the developers to choose their own directory structure

The changes required to reach these goals are few and simple.

The 14 associated pull requests are ready to be submitted, waiting for approval of this proposal. If it can help on making the good decision, I would be really pleased to submit these pull requests before approval.

On a personal note, I think that suggesting and not enforcing a directory structure conforms well with the Laravel philosophy.

New Configurable Paths

The goal is to remove the hardcoded app paths from laravel/framework and replace them with configurable values, defined in the bootstrap/paths.php config file (except for logs and cache views). Here is the proposed new bootstrap/paths.php. Here are the new configurable paths with their associated keys and proposals :

/commands (path.commands)

Only the Artisan command command:make explicitly refers to the commands path. Though that path could be overridden using the --path option, I think that it would be interesting to remove the hardcoded path for the sake of completeness.

/config (path.config)

The reference to the config folder in Foundation/Application.php, PublisherServiceProvider, and the key:generate command could be removed and replaced with the new key path.config.

/controllers (path.controllers)

As for the commands folder, the change is not really necessary ; only Artisan commands refer to that folder, and the hardcoded controllers can be overridden using the --path option.

/lang (path.lang)

Only the TranslationServiceProvider uses that path, which could be changed to the new key path.lang.

/database/migrations (path.migrations)

Various commands refer to that path ; it could be easily replaced with the new key path.migrations.

/start (path.start)

Why shouldn't the start path be configurable ? Foundation/start.php and Console/Application could be updated to use the new path.start key.

/storage/logs (log.file on framework and laravel)

Not really sure about this one. The log file is specified in 3 places : in start/global.php, which is fine, and twice in the TailCommand, once for local tailing and once for remote tailing. The TailCommand allows to choose the file to tail using the --path option, so the hardcoded path can be bypassed.

Anyway, to replace the 3 occurrences, a new configuration file could be created config/log.php, which would contain a file key specifying the path to the log file (maybe the key should be named path ?). To avoid a BC, the old hardcoded path can be kept in the TailCommand code :

$path = $this->laravel['config']['log.file'] ?: storage_path().'/logs/laravel.log';

/storage/views (view.cache on framework and laravel)

The cache used by the view compiler engine is pointing to that path. A new key cache could be created in config/view.php to remove the dependency to that folder. Also, to avoid a BC, the hardcoded value can be kept in the code as a fallback :

$cache = $app['config']['view.cache'] ?: $app['path.storage'].'/views';

/views (path.views on framework and laravel)

This is a tricky one, as the view paths are configured in config/view.php. A solution could be to move the main view path to bootstrap/paths.php, and to specify only the additional paths in config/view.php.

$paths = $app['config']['view.paths'];
array_unshift($paths, $app['path.views']); // <= suggested line

PublisherServiceProvider, ServiceProvider and ViewServiceProvider could be changed to use the new key path.views.

Breaking Change

The addition of a new method getDefaultInstallPaths can avoid a BC, This method could return an array containing the default paths. This array could then be merged with the bootstrap/paths.php array, so that all the expected keys exist.

$paths = array_merge($this->getDefaultInstallPaths(), $paths);

Here is the install path fallback proposal.

Helper functions

I don't think that helper functions such as app_path, base_path, public_path and storage_path are needed for these new configurable paths, as they are kind of underground. Though, it would make sense that all the keys from paths.php have their helper functions. Any comment on this is really welcome.

GrahamCampbell commented 10 years ago

This would need to have an implementation for packages too.

agentphoenix commented 10 years ago

:+1:

ChristopheB commented 10 years ago

I think that an implementation for packages is out of this scope.

GrahamCampbell commented 10 years ago

Not really. This sort of change would create an inconsistency with package design.

ChristopheB commented 10 years ago

Packages follow the recommended directory structure proposed by Laravel, so they can be shared and parsed correctly. This is fine to me, and doesn't directly relate to the app structure folder (except for the fact that, yes, it wouldn't be the same structure).

What would you suggest ?

taylorotwell commented 10 years ago

Honestly I don't think we need this level of configuration. Most people do not care and just want a convention.

ChristopheB commented 10 years ago

As you want, though I wished we could have discussed it a bit more :)

I hear your concern about making official the possibility of changing the directory structure. But I still think that removing the hardcoding paths from the framework and keeping them all in one place is a good thing.

It can be done with this proposal, simply by letting the bootstrap/paths.php as it is today, without the new keys. The install path fallback getDefaultInstallPaths() would then populate the keys.

For the record, here are the proposed changes (I updated my first post) :

the new bootstrap/paths.php (that shouldn't be merged if we don't want to make this functionality official)
the install path fallback, to regroup all the paths and to avoid BC
path.commands
path.config
path.controllers
path.lang
path.migrations
path.start
log.file on laravel/framework and log.file on laravel/laravel
view.cache on laravel/framework and view.cache on laravel/laravel
path.views on laravel/framework and path.views on laravel/laravel

ChristopheB commented 10 years ago

Not directly related, but here is an interesting discussion about the directory structure of Symfony Standard : https://github.com/symfony/symfony-standard/issues/584

ZEALi commented 10 years ago

really need to be able to change the config directory at least.

joshmanders commented 10 years ago

:+1:

leemason commented 10 years ago

+1000000000000000000 for this, i think I've mentioned the config folder before.

i know "most" people wont even care about this, but there will always those that do. And the solution provided means people who don't care wont even have to know about it.

its a few lines of code to please quite a few people.

i get convention over configuration, but to me flat refusing this is more of a law than convention.

The reason i love laravel is because i can swap out the view factory, or i can extend different classes and bind them back into the brilliant container.

As it stands i can fundamentally change the way the core application works, or what providers are loaded, or what view engine i want to use, but can't even change a directory name for my config files as it will break everything?????????

taylorotwell commented 10 years ago

This is fixed in 4.3.

On August 21, 2014 at 4:31:10 PM, Lee Mason (notifications@github.com) wrote:

+1000000000000000000 for this, i think I've mentioned the config folder before.

i know "most" people wont even care about this, but there will always those that do. And the solution provided means people who don't care wont even have to know about it.

its a few lines of code to please quite a few people.

i get convention over configuration, but to me flat refusing this is more of a law than convention.

The reason i love laravel is because i can swap out the view factory, or i can extend different classes and bind them back into the brilliant container.

As it stands i can fundamentally change the way the core application works, or what providers are loaded, or what view engine i want to use, but can't even change a directory name for my config files as it will break everything?????????

— Reply to this email directly or view it on GitHub.

leemason commented 10 years ago

perfect, once again taylor you come through for us.

just had a quick look at dev and love the new structure. funnily enough its very similar to how i was trying to get app before we could.

i assume all these changes will be detailed when 4.3 is out (november right?)

taylorotwell commented 10 years ago

Yes.

taylorotwell commented 10 years ago

I will be discussing it all at Laracon EU next week.

leemason commented 10 years ago

looks like ill be busy reading up on it then. thanks again taylor for all your work.

ChristopheB commented 10 years ago

Glad to hear that ! :+1:

foxmedo commented 9 years ago

it's very important for us also, is this possible with Laravel 5.1

triadsk commented 9 years ago

I'm also interested if this can be achieved in L5 too.

roydekleijn commented 7 years ago

yes, is this already possible?

foxmedo commented 7 years ago

yes our R&D team has change the directories structure and it work very well but each time you need to upgrade the framwork you need to make all this changes manually,

for us we are using LTS version so we don't need to upgrade the framwork and we have build a lot of application over this new structre

roydekleijn commented 7 years ago

So, there is no way to set the paths when instantiating

$app = new Illuminate\Foundation\Application(

??

It would be very nice if we can set the path in the bootstrap script.

On Fri, Jan 6, 2017 at 3:46 PM, Foxmedo notifications@github.com wrote:

yes our R&D team has change the directories structure and it work very well but each time you need to upgrade the framwork you need to make all this changes manually,

for us we are using LTS version so we don't need to upgrade the framwork and we have build a lot of application over this new structre

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/3984#issuecomment-270917433, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPP1V_udlyHLgMXJ-EM2ABjwoiTXkl_ks5rPlPegaJpZM4BsSHz .

--

[image: --] Roy de Kleijn [image: http://]about.me/roydekleijn http://about.me/roydekleijn?promo=email_sig

eusonlito commented 7 years ago

On my view, I love the previous Laravel 4 paths definition, all files related with "app" environment into "app" folder (config, storage, resources, etc...). It was easy to create multiple environments (isolated) into a unique Laravel installation, now you can't do it. Main project folders are common and others are into app folder, why?

Now it's difficult to start/share projects from a common "app". Even is worst to text editor project definition (like Sublime Text), now you have more folders that you need.

Previously, all outside "app" and "public" folders was a Laravel domain, and inside "app" and "public" was a developer domain, now is all mixed.

I hope that my comment will be taken as constructive :)

noyessie commented 6 years ago

@foxmedo Please can you help me to achieve this. what tutorial, what precaution ...

I want to have a modular laravel structure where all the (controller, views, ... ) can be regrouped by module. thank in advance.

devcircus commented 6 years ago

@noyessie Google "laravel modular structure". There are lots of options available, like this one.

noyessie commented 6 years ago

thank you

2018-02-20 15:15 GMT+01:00 Clayton Stone notifications@github.com:

@noyessie https://github.com/noyessie Google "laravel modular structure". There are lots of options available, like this one https://nicolaswidart.com/blog/writing-modular-applications-with-laravel-modules .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/laravel/framework/issues/3984#issuecomment-366989913, or mute the thread https://github.com/notifications/unsubscribe-auth/AJH_U_MsBLKgK-SVI8OjPNPdM95TAZSDks5tWtOCgaJpZM4BsSHz .

-- Hubert Noyessie ----------------------------------- Ingénieur Polytechnicien, Génie Informatique, Promotion 2017 Tel : +237 <+237%206%2090%2023%2082%2030>695749759 / +237 683375353 Email : hubertnoyessie@gmail.com rostandyoba2014@gmail.com

foxmedo commented 6 years ago

unfortunate but we have stopped working with laravel a few months ago, we have returned to our old platform based on CodeIgniter, packages in laravel doesn't follow laravel updates, and laravel create each time new structure which disrupts our work. we are working on large scale application and we need stable framwork

laravel / framework