2

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.

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer
2
  • 1
    Following up here - I'm glad I chose this path, it has not introduced any issues and is MUCH more manageable than "repository per module" Commented May 12, 2022 at 15:00
  • 1
    Thanks for asking, answering and following-up on your own question John. I have seen both and even though having individual repositories for each module looks cleaner I agree that it adds to the development effort. Commented Mar 1, 2023 at 19:53

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.