Group Kiota PHP repositories

[andrueastman]

Related to microsoft/kiota#4636 and microsoft/kiota-dotnet#238

As a language specific concern, we should look into the feasibility of grouping the repos and outline if this is not feasible in this issue.

[baywet]

Whenever this is completed we should also:

• update the quickstart samples feat: upgrades samples to bundle kiota-samples#6457
• update the quickstart documenation feat: adds dependencies filter documentation MicrosoftDocs/openapi-docs#110

[Ndiritu]

(Subject to future edits as investigation continues, but edits will be listed here)

Composer (dependency manager) supports linking between sub-projects, however Packagist (dependency repository) doesn't support deployments from sub-packages. Packagist expects a package to be hosted within a GitHub repository whose root folder contains a composer.json file. Reference

Currently, package deployment works like this, our PHP repos have a Packagist GitHub app set up & a webhook that triggers publishing to Packagist when a tag is created. The version of the packages is determined by the tag or adding a "version" property to the composer.json.

With a mono-repo, our limitation would be in the deployment process.

Various tools exist that split the mono-repo into repositories during deployment & pushes commits & tags to the new repos so that deployment happens.

Two major tools seem viable for this:

Mono-repo builder

which provides various CLI utilities to validate our dependency versions across sub-projects & release automations which we shouldn't need courtesy of release-please. It does the repo split using a release workflow with the monorepo-split-github-action & providing it with repo:write permissions to split the repository and publish. Mono-repo builder has ~3M+ installs & seems stable at v11.x

Splitsh-lite

which does only the repo subtree split and has been used by Google Cloud PHP mono-repo to deploy their various service libraries as separate packages ref. They augment this with their own custom scripts.

Mono-repo builder seems most viable however it still leaves us potentially with our individual repositories for abstractions, http etc but we can manage everything via a kiota-php repository.

Pending:

• Prototype using Mono-repo builder to find any further pitfalls

[Ndiritu]

Open to further feedback here @andrueastman, @baywet, @shemogumbe

[baywet]

Thank you for the additional information.

So if I'm following things properly, in those scenarios we'd:

• create a mono-repo.
• migrate the "live" version of the code there.
• setup some kind of automation to replicate onto existing repos. (so that packagist webhook is triggered, and the platform has "something to refer to")

Or am I missing anything here?

[Ndiritu]

Yes, create a mono-repo. We could keep the current repos for the core libraries for to re-use the current Packagist webhook configs.
I will confirm all details once I run a PoC within the week.

[baywet]

Thanks! The two things I'd want us to get clarity on before we make any decision are:

• Is there a chance that the "packages from the monorepo" could appear in packagist by mistake? that people could take a dependency on them?
• Would "deleting" the existing repos be a breaking change to people who already have a reference to the packages on packagist? (I'm fairly confident the answer to this one is yes)