5 ms·

Thank you for this reply. Can you give a bit more detail on what you mean? For example, I will have a .github folder I'll need for CI/CD workflows used across

Thank you for this reply. Can you give a bit more detail on what you mean? For example, I will have a .github folder I'll need for CI/CD workflows used across the monorepo. This is sort of becoming my go-to tool for devops things in addition to deployment. Are there other repo-maintenance type folders I should be thinking about that you specifically have in mind? Did you mean to start a tree one directory removed from root so that the root has only a sparse set? What I mean to say is for your pkg/ example, have all services / apps leap off that folder rather than root? If you have any feedback on issue management as I mentioned in my other replies, also happy to take any feedback.

jjgreen 6y ago
Typically you're going to have a pile of scripts for CI, development setup, deployment, so may as well have those in bin/ systematically. To avoid having configuration files clogging up the bottom-level, put those in etc/, and so on. Maybe also share/ for common library code (which could be symlinked into per-plugin locations if you wanted them to be self-contained (git handles symlinks gracefully except on Windows I understand). A doc/ directory maybe? It's likely that the amount of this whole-repo administration code will increase with time, so worthwhile having it with some structure from the start -- the /bin, /etc ... conventions are from Unix of course, but perhaps your team has other roots, in which case whatever works for you. I would advise having these as non-hidden directories with short lower-case names without spaces, makes it easier to script; and README.md files so the documentation is nice & visible on GitHub etc. And yes, the "real" per-project directories in a subdirectory, pkg/, client/, product/, something likes that. Re issues, I've previously used tags to reasonable effect. Not as convenient as per-repo issues, but that's one of the downsides to monorepos. I think the benefits outweigh those.

jjgreen 6y ago

Typically you're going to have a pile of scripts for CI, development setup, deployment, so may as well have those in bin/ systematically. To avoid having configuration files clogging up the bottom-level, put those in etc/, and so on. Maybe also share/ for common library code (which could be symlinked into per-plugin locations if you wanted them to be self-contained (git handles symlinks gracefully except on Windows I understand). A doc/ directory maybe? It's likely that the amount of this whole-repo administration code will increase with time, so worthwhile having it with some structure from the start -- the /bin, /etc ... conventions are from Unix of course, but perhaps your team has other roots, in which case whatever works for you. I would advise having these as non-hidden directories with short lower-case names without spaces, makes it easier to script; and README.md files so the documentation is nice & visible on GitHub etc. And yes, the "real" per-project directories in a subdirectory, pkg/, client/, product/, something likes that. Re issues, I've previously used tags to reasonable effect. Not as convenient as per-repo issues, but that's one of the downsides to monorepos. I think the benefits outweigh those.