Download the PHP package shopsys/monorepo-builder without Composer
On this page you can find all versions of the php package shopsys/monorepo-builder. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download shopsys/monorepo-builder
More information about shopsys/monorepo-builder
Files in shopsys/monorepo-builder
Package monorepo-builder
Short Description [FORK] Not only Composer tools to build a Monorepo.
License
Informations about the package monorepo-builder
Not only Composer tools to build a Monorepo
Do you maintain a monorepo with more packages?
This package has few useful tools, that will make that easier.
Install
Usage
0. Are you New to Monorepo?
The best to lean-in fast is to read basic intro at goMonorepo.com. We also made a simple command to make that easy for you:
And the basic setup is done!
1. Merge local composer.json
to the Root One
Merges configured sections to the root composer.json
, so you can only edit composer.json
of particular packages and let script to synchronize it.
To merge just run:
Typical location for packages is /packages
. But what if you have different naming or extra /projects
directory?
Sections are sorted for you by saint defaults. Do you want change the order? Just override section_order
parameter.
After Merge Options
Do you need to add or remove some packages only to root composer.json
?
2. Bump Package Inter-dependencies
Let's say you release symplify/symplify
4.0 and you need package to depend on version ^4.0
for each other:
3. Keep Synchronized Package Version
In synchronized monorepo, it's common to use same package version to prevent bugs and WTFs. So if one of your package uses symfony/console
3.4 and the other symfony/console
4.1, this will tell you:
4. Keep Package Alias Up-To-Date
You can see this even if there is already version 3.0 out:
Not good. Get rid of this manual work and add this command to your release workflow:
This will add alias 3.1-dev
to composer.json
in each package.
If you prefer 3.1.x-dev
over default 3.1-dev
, you can configure it:
5. Split Directories to Git Repositories
Classic use case for monorepo is to synchronize last tag and the master
branch to allow testing of @dev
version.
And run by:
To speed up the process about 50-60 %, all repositories are synchronized in parallel.
6. Release Flow
When a new version of your package is released, you have to do many manual steps:
- bump mutual dependencies,
- tag this version,
git push
with tag,- change
CHANGELOG.md
title Unreleated tov<version> - Y-m-d
format - bump alias and mutual dependency to next version alias
But what if you forget one or do it in wrong order? Everything will crash!
The release
command will make you safe:
Are you afraid to tag and push? Use --dry-run
to see only descriptions:
7. Set Your Own Release Flow
There is set of few default release workers - classes that implement Symplify\MonorepoBuilder\Release\Contract\ReleaseWorker\ReleaseWorkerInterface
.
You can extend it by adding your own:
And or disable default ones:
Contributing
Open an issue or send a pull-request to main repository.
All versions of monorepo-builder with dependencies
composer/composer Version ^1.8
nette/utils Version ^2.5
phar-io/version Version ^2.0
symfony/finder Version ^3.4|^4.1
symfony/dependency-injection Version ^3.4|^4.1
symfony/console Version ^3.4|^4.1
symplify/package-builder Version ^5.4.6