How to organize multiple repositories on github for a complex application?

Question

GitHub

Good afternoon.
There is a project that we want to give to open source. To do this, we plan to post the code on github. The software was originally created with an eye on free distribution, so the languages ​​\u200b\u200bare used mainstream, muscle instead of postgres, etc. But with the form in which to lay out the code there are some difficulties.
The software itself consists of two parts: a REST server in php and a singlepage application in ts + react. By themselves, they were developed independently. The only thing that connects them is that for the client, you need to specify the address of the rest of the server, and for the server, add the client's domain to the list of valid domains for CORS.
At the moment we have two turnips: client and server.
But you need to store documentation somewhere else. Documentation is needed general, such as an instruction manual and for programmers who will finish it for themselves (a description of the general logic).
We also use apidocs on the server. Those, the code needs to generate a fresh one for themselves. But for convenience, it would be necessary to store it ready-made somewhere, for example, on github pages.
It turns out that there is quite a lot of code and it is necessary to store it, albeit separately, but together. For this, we decided to start an organization on a github and make a rap from it: for the core, for the docks, for examples. Everything seems to be clear here.
But I'm interested in one question: is it better to store the client and server parts in the same turnip or in different ones? The fact that the code is divided speaks in favor of two separate raps. And the one who will change one part will not have to pull the other. But in this case, for a normal deployment, it will be necessary to pump out and collect two turnips already.
Tell me, who has experience in maintaining such composite projects on github, how will it be more convenient for developers, contributors and users? I would be grateful for any thoughts in this regard.

Answer 1

Package PHP as composer packages, then the whole project will be assembled easily and simply. It's great if you can set up `composer build-project` for fast deployment. There is also a solution on top of the composer for managing configs and statics: Puli . Try it, it might work for you.
It is better to duplicate the client code with compiled files (put js next to ts and, if possible, min.js). Dependencies again through the manager npm/bower/... If the frontend is a separate application, then, accordingly, into a separate turnip.
Documentation (the one that is generated from apidoc) is better to keep closer to the code (in the same repository) - it will be easier to deal with desynchronization of code and documentation. Automatically get documentation linked to the code version.
For general documentation - a separate repository + github pages (although it is possible to arrange it through wiki sections)
You can make a separate repository with an example application, where all dependencies will be indicated and an example config will be present.
But in general, in order to group the whole thing and conveniently manage access, organize a group on github and place all thematic repositories in it.

Answer 2

Everything is separate.

But in this case, for a normal deployment, it will be necessary to pump out and collect two turnips already.

It's OK.