pklaschka
commented
3 years ago While I'm, generally speaking, open to that idea, I believe there are a few areas in which development workflows, as far as I know, are very different, and thus, difficult to combine (or could compromise practicability to an extend where the benefits no longer outweigh the costs):
- The frontend repos, without exception, have a highly automated release system that has to be "releasable" at any time and then, automatically, by parsing the commit messages, generates CHANGELOG, release notes, etc., which are very much invaluable tools for development. At least, for now, I haven't seen that kind of workflow in the backend repos, making it a potential "friction point" between the workflows
- Putting everything in one repo would create a tight coupling between the two areas. While this, in theory, sounds good, it also means every tiny "patch" would have to be a coordinated release effort: Right now, I can just quickly fix something, press the "release" button, and everything else gets done automatically (with the exception for building non-Linux artifacts in CI, which will follow soon). All in all, I can, as it is now, very quickly fix a bug without a long round-trip of knowing if the backend aspect is currently "release-ready."
- As the tech stacks are severely different, integration isn't as simple as it might seem. While it's probably not impossible, frontend repos tend to work best with a lot of tooling that exists if specific configuration files are at the root of the repository (and not, e.g., in
/client), and so on. Like probably most other "realms", React-based applications (or JS-based apps in general) have many best practices and excellent tooling that's easy to configure when following those best practices. I'm not saying it's impossible to configure it in another way. Still, it definitely makes things a lot more complicated, which, considering we're having a lot of "Junior-grade" developers just learning to use those tools, I'm reluctant to add that additional layer of complexity (and "teaching" non-standard things, as it is right now, it's easy to find answers on Stack Overflow, etc.)
Last but not least, regarding "don't need to maintain two repositories,": Although it seems counter-intuitive, at first, in my experience, the complexity of maintaining vastly different codebases (which we have here) in a single repository adds far more complexity than the fact that it's just one repo reduces. I've never seen a project that has tried it and didn't roll back later.
This, of course, leaves the benefit of a single "starting point". I cannot and don't want to argue with that. But, all things considered, in my opinion, the benefits it provides don't outweigh the cost introduced by the points above.
It may be that I see problems where there are none, and I'm very much open to having further discussions surrounding the idea, but for now, I have to say that I don't think its benefits outweigh the costs, leaving me to oppose the idea, as of right now...
fussel178
I think it is a good idea to have one repository for the projects containing all the project code. So we don't need to maintain two repositories for the same project and have a single starting point. Since both code bases are not inferring with each other we could easily copy the files.