Flyokai monorepo

This repository is the single source of truth for all flyokai/* packages. You commit and push here once; the per-package repositories under https://github.com/flyokai are read-only mirrors produced by splitting.

flyokai/                       # this repo  (flyokai/flyokai)
├── composer.json              # the flyokai/flyokai metapackage (published from root)
├── monorepo-builder.php       # optional: version sync / interdependency bumping
├── bin/flyokai-split.sh       # local split -> read-only repos
├── .github/workflows/
│   ├── ci.yml                 # tests
│   └── split.yml              # split to read-only repos (manual: workflow_dispatch)
├── packages/                  # 29 Flyokai packages -> flyokai/<name>
│   ├── data-mate/
│   └── …
└── plugins/                   # Shopware plugins
    ├── FlyokaiMarketplace/        -> flyokai/sw-marketplace
    └── FlyokaiMarketplaceRemote/  -> flyokai/sw-marketplace-remote

History for every package was imported with git filter-repo --to-subdirectory-filter, so git log / git blame on any path inside packages/ and plugins/ shows the package's full original history.

Third-party forks (NOT in the monorepo)

These are vendored forks of upstream libraries — they keep their upstream namespace and history and live as standalone repos, consumed via composer VCS entries (as before), not as path repos here:

Package	Namespace	Repo
flyokai/amphp-injector	Amp\Injector\	flyokai/amphp-injector
flyokai/laminas-db	Laminas\Db\	flyokai/laminas-db
flyokai/revolt-event-loop	Revolt\	flyokai/revolt-event-loop
flyokai/zend-db-sql-insertmultiple	Laminas\Db\	flyokai/zend-db-sql-insertmultiple

The monorepo packages depend on them normally; the metapackage still requires them. Consuming installs keep VCS repository entries for these four.

Using the packages from an install (composer path repositories)

Point the consuming project (a Shopware/Magento install, the data-service sandbox, …) at a checkout of this monorepo with two wildcard path repos instead of dozens of VCS entries:

{
  "repositories": [
    { "type": "path", "url": "/www/sw6710/flyokai/packages/*" },
    { "type": "path", "url": "/www/sw6710/flyokai/plugins/*" }
  ],
  "minimum-stability": "dev",
  "prefer-stable": true
}

Then composer require flyokai/data-mate:@dev (etc.) — composer symlinks the package straight from the monorepo, so edits are live.

Parallel feature work

Each working copy is one branch of the monorepo, paired with one install:

Monorepo checkout	Branch	Paired install
/www/sw6710/flyokai	feature/x	sw6710
/www/sw679/flyokai	bugfix/y	sw679
/www/sw6610/flyokai	main	sw6610

Use git worktree so the clones share one object store:

# from any existing checkout
git worktree add /www/sw679/flyokai -b bugfix/y
git worktree add /www/sw6610/flyokai main

Each install's path repos point at its own monorepo checkout, so the branches stay isolated.

Splitting to the read-only repos

The standalone flyokai/* repos are outputs. Don't commit to them directly.

Not enabled yet. Splitting is held until the "collapse mirrors to a single main" decision is made. The CI workflow's push: trigger is commented out (manual workflow_dispatch only), and bin/flyokai-split.sh is dry-run by default. Nothing writes to the mirrors until you opt in.

• CI: .github/workflows/split.yml (run manually via workflow_dispatch, or re-enable the push: trigger). Mirrors each subtree out via danharrin/monorepo-split. Needs a SPLIT_TOKEN repo secret — a PAT with write access to the org repos (the built-in GITHUB_TOKEN only covers this repo).

• Local: bin/flyokai-split.sh (dry run by default).

bin/flyokai-split.sh data-mate          # dry run, one package
BRANCH=dev bin/flyokai-split.sh         # dry run, would target the dev branch
APPLY=1 bin/flyokai-split.sh            # force-push ALL to the read-only repos' main

The first real split force-pushes monorepo-derived history over whatever the standalone repos currently hold (on the chosen BRANCH, default main). That is intentional — from then on they are mirrors of this monorepo.