Rename app/code to app/modules

[apiuser]

Feature request from colinmollenhour, posted on GitHub Sep 08, 2013

It seems that with all of the module components being moved into the app/code directories that the name "code" for this directory is far too specific and "modules" would be more appropriate.

[apiuser]

Comment from orlangur, posted on GitHub Jan 18, 2015

Symfony can demand to the Composer autoloader the responsibility to locate a bundle on the filesystem

I would like to avoid such flexibility by convention over configuration.

So, if there is no app/code directory and module list loader searches for module.xml in vendor/*/*/etc/module.xml - is there still some crucial difference between app/etc/config.php and Symfony approach?

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 19, 2015

I would like to avoid such flexibility by convention over configuration.

Why?

So, if there is no app/code directory and module list loader searches for module.xml in vendor///etc/module.xml - is there still some crucial difference between app/etc/config.php and Symfony approach?

I already explained what are the differences between the two approaches. I don't know if these differences are crucial for you.

Anyway I agree with your proposal of searching modules in vendor/*/*/etc/module.xml so at least we can remove the dependance on magento/magento-composer-installer and not have duplicated files anymore.

Would you like that I work on PR for this?

[apiuser]

Comment from alankent, posted on GitHub Jan 19, 2015

I would like to see modules, themes, lang packs under app or vendor. So can have local modules for your project without uploading to a repo. Problem was base directory (look at prev comments above). Please let us know where this effort occurs so can keep in sync with internal work

[apiuser]

Comment from orlangur, posted on GitHub Jan 24, 2015

Why?

To make the things simpler. If we have vendor folder, no need to invent some additional places for modules. Let's just make all of them follow the same convention.

I would like to see modules, themes, lang packs under app or vendor

Totally second this, also, would like to see magento/framework split into components. With such approach no custom composer package types will be needed.

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 28, 2015

To make the things simpler. If we have vendor folder, no need to invent some additional places for modules. Let's just make all of them follow the same convention.

I didn't understand.

[apiuser]

Comment from orlangur, posted on GitHub Jan 28, 2015

Looking at Symfony way it looks like PHP class corresponding to bundle configuration could be placed anywhere.

With convention over configuration we just define one particular place where module configuration files could be placed. So, vendor/*/*/etc/module.xml is a strict rule, no sub-folders or placing modules into app/code or any other place is supposed to be allowed.

[apiuser]

Comment from davidalger, posted on GitHub Jan 28, 2015

@orlangur What you propose will not work for anything but sites which use only vendor code. Custom modules written for a specific site do not belong in vendor and would (in almost all cases) not be found in a composer repository. These should be in a separate location specifically for modules which are custom made for the site. This is why @alankent said he'd like to "see modules, themes, lang packs under app or vendor" — they can't be under one or the other, but should be supported in either location, with vendor being used for 3rd party vendor code and under app where it's non-distributed custom code specific to the build.

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 28, 2015

Looking at Symfony way it looks like PHP class corresponding to bundle configuration could be placed anywhere. With convention over configuration we just define one particular place where module configuration files could be placed. So, vendor///etc/module.xml is a strict rule, no sub-folders or placing modules into app/code or any other place is supposed to be allowed.

And do you think that this is a good solution?

In this way when working on a particular project I'm forced to have all modules under vendor, even those modules specific for that project. As @alankent said (and I agree with him) the Magento Framework should support module loading from both app/code and vendor. In this way we could have project-specific modules in app/code and external (re-usable) modules in vendor (installed with composer). So, one more time, I think that the Symfony's could-be-placed-anywhere approach is better.

So please, let me know, what goal do you want to achieve:

1. Modules loaded only from app/code. This is the current behavior and I think that is bad because it requires magento/magento-composer-installer and related problems already listed above.
2. Modules loaded only from vendor. I think that this is bad for the same reasons stated by @DavidAlger.
3. Modules loaded both from app/code and vendor. I think that this is the optimal behavior.

Let me know.

[apiuser]

Comment from alankent, posted on GitHub Jan 28, 2015

We tried to allow downloaded modules to stay under vendor, but hit a problem with the code not being flexible enough. Architecturally, I personally like the main site getting the list of module directories from a configuration file created by the setup process. That is, let them be anywhere! Setup can have conventions like only looking in vendor and app/code (or app/modules) to create this config file. Scan back up the comment history for "The complexities highlighted were a result of a single base path variable used throughout the code" for more details. We want to do it, there is a plan, it just proved harder to do than expected. We trade effort off against business value when defining our internal backlog.

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 29, 2015

Hi @alankent,

We tried to allow downloaded modules to stay under vendor, but hit a problem with the code not being flexible enough.

Yes it's true. Unfortunately, there are a lot of components in Magento Framework that assume that there is only one modules base directory. It's sufficient to search the usages of the \Magento\Framework\App\Filesystem\DirectoryList::MODULES constant in the Magento Framework to find a list of components based on this assumption.

We want to do it, there is a plan, it just proved harder to do than expected. We trade effort off against business value when defining our internal backlog.

Ok I understand that, it's fine. Can you tell us when approximately this could be fixed?