What’s New in Pricore 0.57: Monorepo Support

Plenty of PHP teams keep related packages together in one repository. A billing module, an auth SDK and a shared notifications package live side by side, get reviewed in the same pull request and are tagged together. Until now, Pricore only read the composer.json at the root of a repository, so a monorepo like that either had to be split into read-only mirrors or couldn’t be served at all.

v0.57.0 adds monorepo support. Point Pricore at the directories that hold your packages, and it serves each of them as its own Composer package.

Package paths

When you connect a repository, or later from its Edit page, you can list the directories where your packages live. Each line is a path relative to the repository root:

Pattern	Selects
packages/billing	That directory
packages/*	Every directory directly under packages
*	Every directory at the repository root
.	The repository root itself

Take a repository laid out like this:

acme/platform
├── composer.json
└── packages
    ├── auth-sdk/composer.json
    ├── billing/composer.json
    └── notifications/composer.json

With packages/* as the only path, Pricore creates three packages: acme/auth-sdk, acme/billing and acme/notifications. The root composer.json is left out, because in most monorepos it describes the repository rather than a package you publish. Add . if you want it synced too.

Your team installs them like any other package:

composer require acme/billing

One tag, a version for every package

Every tag and branch is read once per package. Tag v1.2.0 on the monorepo and each package present at that tag gets a v1.2.0 version. A package that didn’t exist yet at an older tag simply has no version there.

Packages from a subdirectory are installed from Pricore’s dist archives, since Composer can’t check out a single directory from Git. Pricore builds an archive for each package and version, and offers the version to Composer once its archive is ready. Keep dist archives enabled for these packages.

README links and images resolve against the package’s own directory, so relative links in packages/billing/README.md keep working on the package page.

Changing paths later

Saving different package paths starts a full sync, or queues one if a sync is already running. Packages that no longer have any versions under the selected paths are removed along with their versions and archives. A package that moved to a different directory keeps the versions that are still selected.

Safer syncs for every repository

Building monorepo support meant looking closely at how a sync handles missing or broken packages. Those improvements apply to single-package repositories too:

• Removed packages. When a composer.json disappears from a branch or tag, that version is removed on the next sync. Other versions of the package are kept.
• Invalid composer.json. A composer.json that fails to parse skips only that package, which keeps its existing version. Other packages at the same tag or branch still sync.
• Name conflicts. A repository can no longer attach versions to a package name that already belongs to another repository or mirror in your organization. The sync skips that package and logs a warning.
• Forced syncs. php artisan sync:repository --force revisits every tag and branch, even when its commit hasn’t changed.

This release also fixes a branch without a composer.json on GitHub or GitLab failing the whole sync, Composer offering a version that was already deleted, and a reused Git clone missing new tags.

Upgrading

This release adds columns for package paths.

• Docker: migrations run automatically when the container starts, so pulling the new image is enough.
• Manual installations: run php artisan migrate after updating.

Per-package tag prefixes such as billing/v1.2.0 are not supported. Tag the monorepo once per release.

• Release notes: View every Pricore release
• Documentation: Set up a monorepo
• Cloud: Start your 14-day free trial
• Self-hosted: View Pricore on GitHub