Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor code so modules/themes/language packs can exist under different directories (such as 'vendor') #1013
Currently we cannot leave modules (and themes and language packs) downloaded via Magento in the 'vendor' directory. We tried to convert the code, but hit a problem. TexanHogman (Rick) described it well here: #357 (comment).
The goal is to allow modules to reside under 'vendor' or 'app/modules' (renamed from 'app/code'). Currently there are file path patterns coded into the system (such as app/code///etc/module.xml) that make putting modules in different locations harder. (I personally would prefer to get the list of directories from the config.php file, worked out by the setup script, allowing modules to sit anywhere in the directory tree giving the developer greater freedom of how to lay out their code during development.)
The real problem is other areas of the code, like functional and integration tests, have too many dependencies on the current locations of files. One approach is to say "tests are only usable if you git clone the master repository". This is not ideal however. Production sites should never use git clone. They should use Composer to download official release versions of modules to ensure they are using a stable release version of the code. This is important for receiving Magento or extension developer support. So it is desirable to rework all the test cases to not depend on the current location of modules and other assets.
This work was started internally, but lowered in priority when the effort required to clean up the tests was fully understood. It is valuable, but there is other higher value / lower cost work that is being planned first. (Also note the internal project had a wider scope of changes than described in this request. This request focuses purely on allowing modules/themes/language packs to reside under 'vendor', with the goal of using Composer without modification or extension.) Offers of community contribution are welcome.
The following is a list of areas that may be affected as an illustration of types of changes likely to be needed:
The following is out of scope for this request:
See also #357 for related discussion.
Given the potential complexity of this task, it is recommended to come up with a proposal to allow the root directory of each module be determined and get that reviewed before commencing with implementation work.
[Warning: This request is an experiment to see how well this approach works to outsourcing work and is subject to change or being withdrawn.]
referenced this issue
Apr 20, 2015
If I understand correctly, setting up a new Magento 2 application for an actual client site should be done as follows:
composer create-project magento/community-edition client_project_name -s dev
Ideally, this should put most code in the vendor folder, and as little files as possible in the root folder (similar to the way Symfony applications can be created with Composer).
Currently this is not the case, which poses a challenge for setting up version control: if you don't want to put the Magento 2 source code into version control, you have to create a pretty elaborate
Also, the current situation does not seem to allow performing upgrades to new versions of Magento 2 using
So I expect that these problems are fixed when this issue (#1013) is resolved, though I'm not sure.
@aadmathijssen I see there are couple of questions in your comments:
@joanhe Thanks for the reply!
Regarding the use of
@aadmathijssen That is correct. If Magento adds or removes some modules, it won't reflect in the composer.json. There is some change in next version. It should improve on this issue. You need to use package