Having a monorepository project means to get all applications and components at the same place. This post isn’t about the avantages or drawbacks of this project management strategy, a lot of developer blogged about the advantages or drawbacks. This post is about how to manage your Composer dependencies in the specific case of monorepository based project.
First, have a look of a project folder structure :
The challenge is to define how the differents applications can easily use the
package2. Maybe your first idea is to configure
to reference all components which are in the repository. This looks like :
This method works, but it’s not the best solution because the
of different components is not used. And this is the file which is used to define
components requirement and configuration. Furthermore, there is a duplication of
autoloading configuration: in the components and in each application will used its.
If you read the Composer documentation, there is a concept of “repositories”. A repository is a package source. It’s a list of packages/versions. Composer will look in all your repositories to find the packages your project requires.
It’s possible to add new
repository sources like
and even more. The one which is very interestant in our case is
path. This will
allow to refer to a local repository of the computer.
We’re going to update our
Now, the Composer configuration refers to our local repository, we don’t need to override the component configuration, whereas Composer will load it as any other dependency.
While I made some search about the best way to manage Composer dependencies in a monorepository, I discovered an experimental project, which is an Composer plugin dedicated to manage this project structure. I didn’t test it, but it could be interesting. The project author have blogged about the tool.