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 tzyganu, posted on GitHub Sep 10, 2014

http://martinfowler.com/bliki/TwoHardThings.html

[apiuser]

Comment from fooman, posted on GitHub Jan 05, 2015

I support @kandy's suggestion - currently I do not see a reason to use the app/code/ location (except maybe historical reasons). If we could move all modules into the composer vendor directory (vendor/) this would be a consistent and permanent location for all modules without having to copy/symlink non-core extensions into the app/code directory when installing additional extensions.

[apiuser]

Comment from alankent, posted on GitHub Jan 05, 2015

There was a big proposed directory structure change that did not make it before dev beta - too big/risky. One of the challenges at present is all modules are located by looking for app/code///etc/module.xml (I think). So all modules need to be under the same directory. With the new config.php approach (the list of modules is created by setup script, not at runtime) one idea being played with was to include the path name of each module root directory in config.php as well. Then modules could be located in different places more easily without extra overhead per http request. (There would be more overhead when setup is run, but that does not matter so much.) That would make it easier to put modules under app/code (or better app/modules) as well as vendor/.

Oh, themes into a 'themes' directory instead of 'design' was another possible change.

[apiuser]

Comment from TexanHogman, posted on GitHub Jan 10, 2015

As @alankent mentioned we wanted to make this change (to /vendor) as part of dev beta and again we've looked at it for dev rc. Our struggle was to complete before the release date so the work was suspended. The complexities highlighted were a result of a single base path variable used throughout the code. When the modules were moved this required a new separate variable and we need to address each usage of base path to map to new structure. Not a difficult task but just proved very time consuming and the decision was made to not hold release for this change. I believe it was the primarily the tests that were highly impacted.

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 14, 2015

+1 for modules under vendor. This will maybe remove the needs of magento-composer-installer (https://github.com/magento/magento-composer-installer) for installing third party modules. No more copies or symlinks to exclude from version control.

[apiuser]

Comment from colinmollenhour, posted on GitHub Jan 15, 2015

A concern that I heard voiced by several at the beta forum this week was that it is messy to package an extension into a repo in such a way that is compatible with composer. An example repo would ideally look something like this (subjective of course):

• docs/
• examples/
• lib/
• scripts/
• src/ (this is the only part that belongs in app/code/)
• tests/
• README.md
• LICENSE.txt
• composer.json

Currently I do not know of a way to map the contents of src/ into app/code/ using composer because composer wants to instead place the src/ directory itself into app/code/ like app/code/Vendor/Module/src/.

Of course this can be resolved by using modman but TBH I'd like to see a solution that works without requiring modman since so much progress has been made to reduce the need for symlinks already. Of course I could just be missing some feature of composer that allows one to do this currently (aside from magento-composer-installer which would also be nice to not have to depend on).

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 16, 2015

Hi @colinmollenhour, yes you can map src/ in app/code/Vendor/Module/ with magento/magento-composer-install. To do so, if you have a repo like that, you can put the following mapping in the extra key of the composer.json:

"map": [
    [
        "src",
        "app/code"
    ]
]

But this is not the point. IMHO the real problem is that Magento requires to have modules in app/code. This requirement is a problem because, if you want to manage external modules with composer (and every PHP project should manage external dependency with composer), you need something that copy or symlink files in that location. Actually this something is the magento/magento-composer-installer and the usage of this tool introduces other problems. For example:

• You have to add to VCS ignore every folder/file copied by magento/magento-composer-installer every time you add a module to your composer.json.
• It's hard to modify and push to related upstream a module that you maintain installed with composer in your project. This because module's files are copied to app/code and you have to repeat the changes even in module directory under vendor. It would be much more better to have the module only under vendor so when the module is changed you can commit and push it to the related upstream.
• In the project there are two files defining the same class and using go to method IDE functionality it's messy because it asks to the user which file to open.

I think that a better approach for loading modules is like it's done by Symfony. In Symfony to add a new bundle (or module) you have to add an instance of a dedicated class to the AppKernel (https://github.com/symfony/symfony-standard/blob/2.7/app/AppKernel.php#L8). Then is the bundle instance that knows how it's configuration files are located. This allows to have bundles under vendor because is the autoloader that knows where to locate class files.

[apiuser]

Comment from orlangur, posted on GitHub Jan 16, 2015

@mmenozzi, is there some crucial difference between Symfony approach and module bitmap in app/etc/config.php?

Thus currently you may change composer.json in order to specify modules you need and after that list of active modules will be generated during installation automatically.

[apiuser]

Comment from colinmollenhour, posted on GitHub Jan 16, 2015

@mmenozzi Yes, this is why I stated at the end:

(aside from magento-composer-installer which would also be nice to not have to depend on)

And thank you for mentioning the headache that comes with copying files.. IMO a good solution definitely does not involve duplicating files.

I don't have a solution, but one idea just to get the point across is something like modifying the include path in the autoloader to expect an intermediate directory such that instead of loading My/Module/Model/Foo.php it becomes My/Module/src/Model/Foo.php. However, this breaks PSR convention and many will probably hate this idea because it is ugly..

I personally don't think modman is a bad solution, it just seems like this is a good opportunity to make it unnecessary.

[apiuser]

Comment from mmenozzi, posted on GitHub Jan 17, 2015

Hi @orlangur,

@mmenozzi, is there some crucial difference between Symfony approach and module bitmap in app/etc/config.php? Thus currently you may change composer.json in order to specify modules you need and after that list of active modules will be generated during installation automatically.

maybe I'm missing something but from what I can see the app/etc/config.php it's used only for enable/disable modules but these modules must be already loaded by Magento\Framework\Module\ModuleList\Loader::load(). The difference is that with Symfony a minimum bundle is simply a class implementing Symfony\Component\HttpKernel\Bundle\BundleInterface so Symfony can demand to the Composer autoloader the responsibility to locate a bundle on the filesystem. With Magento2 a minimum module is the etc/module.xml file and is the Magento\Framework\Module\ModuleList\Loader that decide that these module.xml files must be under DirectoryList::MODULES/*/*/etc/module.xml and from here there is the constraint to have modules under DirectoryList::MODULES directory (app/code). This constraint introduces the needing of magento/magento-composer-installer.

It's good to have modules automatically in app/etc/config.php but I'm not worried about manual work that have to be done to enable a module (even in Symfony you have to add a bundle in the AppKernel::registerBundle()); I'm worried about duplicated class files as stated above.

You asked me if there is any crucial difference with Symfony... With Magento we have duplicated class files around the project (so the problems stated above) this doesn't happen with Symfony. So from a pragmatic point of view I answer: yes I think that there is at least one crucial difference.