Do you maintain a monorepo with more packages?
This package has few useful tools, that will make that easier.
composer require symplify/monorepo-builder --dev
The best to lean-in fast is to read basic intro at blog post All You Always Wanted to Know About Monorepo. We also made a simple command to make that easy for you:
vendor/bin/monorepo-builder init
And the basic setup is done!
Merges configured sections to the root composer.json
, so you can only edit composer.json
of particular packages and let script to synchronize it.
Sections that are needed for monorepo to work will be merged:
- 'require'
- 'require-dev'
- 'autoload'
- 'autoload-dev'
- 'repositories'
- 'extra'
To merge run:
vendor/bin/monorepo-builder merge
Typical location for packages is /packages
. But what if you have different naming or extra /projects
directory?
# monorepo-builder.yaml
parameters:
package_directories:
- 'packages'
- 'projects'
Sections are sorted for you by saint defaults. Do you want change the order? Just override section_order
parameter.
To exclude a specific folder for ignoring the composer.json in this folder.
# monorepo-builder.yaml
parameters:
package_directories_excludes:
- 'ExcludeThis'
Do you need to add or remove some packages only to root composer.json
?
# monorepo-builder.yaml
parameters:
data_to_append:
autoload-dev:
psr-4:
'Symplify\Tests\': 'tests'
require-dev:
phpstan/phpstan: '^0.9'
data_to_remove:
require:
# the line is removed by key, so version is irrelevant, thus *
'phpunit/phpunit': '*'
Let's say you release symplify/symplify
4.0 and you need package to depend on version ^4.0
for each other:
vendor/bin/monorepo-builder bump-interdependency "^4.0"
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:
vendor/bin/monorepo-builder validate
You can see this even if there is already version 3.0 out:
{
"extra": {
"branch-alias": {
"dev-master": "2.0-dev"
}
}
}
Not good. Get rid of this manual work and add this command to your release workflow:
vendor/bin/monorepo-builder package-alias
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:
# monorepo-builder.yaml
parameters:
package_alias_format: '<major>.<minor>.x-dev' # default: "<major>.<minor>-dev"
Classic use case for monorepo is to synchronize last tag and the master
branch to allow testing of @dev
version.
# monorepo-builder.yaml
parameters:
directories_to_repositories:
packages/PackageBuilder: '[email protected]:Symplify/PackageBuilder.git'
packagages/MonorepoBuilder: '[email protected]:Symplify/MonorepoBuilder.git'
And run by:
vendor/bin/monorepo-builder split
To speed up the process about 50-60 %, all repositories are synchronized in parallel.
If you want to test on local machine, you can set local targets by creating bare repositories:
mkdir -p [target/path.git]
cd [target/path.git]
git init --bare
# ^^^^^^ bare!!!
Then you can set the target using file://
prefix for absolute path:
# monorepo-builder.yaml
parameters:
directories_to_repositories:
packages/PackageBuilder: 'file:///home/developer/git/PackageBuilder.git'
packages/MonorepoBuilder: 'file:///home/developer/git/MonorepoBuilder.git'
After that you can test the result:
vendor/bin/monorepo-builder split
cd /tmp
git clone /home/developer/git/PackageBuilder.git
cd PackageBuilder
git log
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:
vendor/bin/monorepo-builder release v7.0
Are you afraid to tag and push? Use --dry-run
to see only descriptions:
vendor/bin/monorepo-builder release v7.0 --dry-run
Do you want ot release next patch version, e.g. current v0.7.1
→ next v0.7.2
?
vendor/bin/monorepo-builder release patch
You can use minor
and major
too.
There is set of few default release workers - classes that implement Symplify\MonorepoBuilder\Release\Contract\ReleaseWorker\ReleaseWorkerInterface
.
You need to register them as services. Feel free to start with default ones:
# monorepo-builder.yaml
services:
# release workers - in order to execute
Symplify\MonorepoBuilder\Release\ReleaseWorker\SetCurrentMutualDependenciesReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\AddTagToChangelogReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\TagVersionReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\PushTagReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\SetNextMutualDependenciesReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\UpdateBranchAliasReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\PushNextDevReleaseWorker: null
You can extend it by adding your own:
# monorepo-builder.yaml
services:
# release workers - in order to execute
Symplify\MonorepoBuilder\Release\ReleaseWorker\SetCurrentMutualDependenciesReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\AddTagToChangelogReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\TagVersionReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\PushTagReleaseWorker: null
+ App\MonorepoBuilder\ReleaseWorker\TweetReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\SetNextMutualDependenciesReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\UpdateBranchAliasReleaseWorker: null
Symplify\MonorepoBuilder\Release\ReleaseWorker\PushNextDevReleaseWorker: null
Open an issue or send a pull-request to main repository.