0

Our online business operates on a Magento 2.4.x installation which now has nearly 100 in-house modules that deliver features and functionality specific to our business. Every module has its own Git repository (we use BitBucket for our repositories and Satis to drive our private package server).

During development, we simply used dev-master for all modules which made pushing updates very quick and easy (either with composer or git pull origin master in the module's directory under vendor/mybusiness). The decision to put every Module into its own repo, and version it by itself was deliberate: we felt that there we advantages to this approach, especially when making changes to the public API for one of many modules. So long we followed SEMVER appropriately, we would be immediately aware of when a change we've introduced may cause issues with one of our other modules that maybe has not been worked on in a while.

While this example scenario is true, we're now realizing the downsides of having such a massive web of dependencies e.g. a change to one module might require a handful of other git operations and file changes across many other modules. This does not "feel" right to our development staff.

We are discussing moving all of our modules into the app/code directory, and using Composer only to manage 3rd party modules, essentially treating our collection of modules as a single application. Since our development team is small and in-house, we feel that it is totally manageable for us to handle the occasional merge if two developers just-so-happen to modify the same file in their bug/feature branch and introduce a merge conflict (this problem would not be unique to this proposed change, either).

We do maintain our own repository for the Magento 2 files and folder structure so that we can (for example) version control our own error pages, .htaccess files, etc. This repository contains little more than these sorts of files/folders and the composer.json file that is exactly what ships with Magento 2, with all of our in-house modules and a select few 3rd party modules included. Therefore, we have an "easy" means of moving our modules from being managed by Composer and simply versioning them altogether, but that also has some sort of weird feeling to it.

I would love to hear some input from other devs who maintain a large number of in-house modules for their business's Magneto 2 installation.

0

In searching for more conversation on this subject, I found a post by Alan Kent (previously VP Architecture @ Magento) where he stated:

So my rule is "app/code" is for code for that project alone (no sharing), "vendor" is for composer shared packages.

Therefore, in my circumstance (i.e., maintaining a single, heavily customized installation of Magento 2) it feels that "the right approach" is to include all of our modules and themes in the app directory and treat all module as they exist together as "the application"

We will maintain a single (private) Git repository on BitBucket that contains the Magento 2 folder structure (including all of our modules and themes), other filesystem changes (e.g., custom .htaccess, error pages, configurations, etc.) and of course the composer.json file that includes external dependencies, such as magento/product-community-edition

I will update if this turns out to be a huge problem but it feels right... managing nearly 100 individual repositories is proving to be a burden for our development staff so we're excited for this change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.