Typical directory structure for a project with equally significant server- and client-side parts

user_482668 0
Viewed 183

We are going to publish an open-source library that contains a server-side part (for Web API, extracting meta-data, DB related operations, etc.) written in C# and a client-side part written in TypeScript that does the UI.

Usually, our repositories have a classic structure like:

  • docs/ - the documentation
  • samples/ - some sample projects
  • src/ - the source code of the library itself
  • tests/ - unit and integration tests

However, now I'm not sure how to organize this Git repository since all these parts (except, maybe, sample project that include both parts) will be totally different for client-side and server-side.

So, for now, we came to a structure like this one:

  • samples/
  • client/
    • docs/
    • src/
    • tests/
  • server/
    • docs/
    • src/
    • tests/

However, I'm still not quite sure about this structure and would like to hear any ideas or suggestions from the community.

Possibly, it's better to make it in 2 different repositories? However, we would like to preserve the unified versioning for both client-side and server-side parts and don't want to complicate things without necessity.

typescript asp.net-core .net-core git
1 Answers

You could use git-submodules so that server and client exist separate reports and in one repo that collates them together, but you reference separate repos for both server and client. From the git-submodules docs:

A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.

You could adopt a naming convention like so:

  • project/client
  • project/server
  • project/project

Your directory structure that you have proposed would be maintained, but code would be split across multiple repos.

user_10505070
Related