Do you maintain a monorepo with more packages?
This package has few useful tools, that will make that easier.
composer require symplify/monorepo-builder --devThe 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:
vendor/bin/monorepo-builder initAnd 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.
# monorepo-builder.yml
parameters:
merge_sections:
# default values
- 'require'
- 'require-dev'
- 'autoload'
- 'autoload-dev'
- 'repositories'To merge just run:
vendor/bin/monorepo-builder mergeTypical location for packages is /packages. But what if you have different naming or extra /projects directory?
# monorepo-builder.yml
parameters:
package_directories:
- 'packages'
- 'projects'Sections are sorted for you by saint defaults. Do you want change the order? Just override section_order parameter.
Do you need to add or remove some packages only to root composer.json?
# monorepo-builder.yml
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 validateYou 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-aliasThis 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.yml
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.yml
parameters:
directories_to_repositories:
packages/PackageBuilder: '[email protected]:Symplify/PackageBuilder.git'
packages/MonorepoBuilder: '[email protected]:Symplify/MonorepoBuilder.git'And run by:
vendor/bin/monorepo-builder splitTo speed up the process about 50-60 %, all repositories are synchronized in parallel.
When a new version of your package is released, you have to do many manual steps:
- bump mutual dependencies,
- tag this version,
git pushwith tag,- change
CHANGELOG.mdtitle Unreleated tov<version> - Y-m-dformat - 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.0Are you afraid to tag and push? Use --dry-run to see only descriptions:
vendor/bin/monorepo-builder release v7.0 --dry-runThere is set of few default release workers - classes that implement Symplify\MonorepoBuilder\Release\Contract\ReleaseWorker\ReleaseWorkerInterface.
You can extend it by adding your own:
# monorepo-builder.yml
services:
App\Release\ShareOnTwitterReleaseWorker: ~And or disable default ones:
# monorepo-builder.yml
parameters:
enable_default_release_workers: falseOpen an issue or send a pull-request to main repository.