Maintaining an internal everything-builder at my company, which sets the baseline for the a small set of monorepos: projects/xyz/ # per-project folder co

Maintaining an internal everything-builder at my company, which sets the baseline for the a small set of monorepos: projects/xyz/ # per-project folder configs # per-project configuration files scripts tools patches # per-project selection of patches to be applied to 3rd party imports ... # but no per-project code target/ # anything that becomes part of the build target library-a # Some library tests # Unit tests for that library library-b binary-c binary-d host/ # anything required to build the build target or perform other tasks, such as tests patches # patches to be applied to 3rd party imports tests/ # system and integration tests test-aspect-a test-aspect-b web/ # client-side stuff, like javascript spa-a library-f ... # and a few more domain-specific things that don't really fit well in the categories above Ultimately, I'm unhappy about the split between many of the top-level items and I'm working on resolving that. It has turned out to be mostly superficial? Items that are required to go into the application (i.e. are located in the target path) sometimes turns out to be required for building, i.e. in the host, too. This all leads to odd definitions inside each item for the project-builder. Everything that has already gone into the "flat" target folder, however, is quite happy there, though it is sometimes off-putting to new colleagues. Ultimately, it's easy to review which parts are included where by reviewing the project configuration files and this is also the main focus when merging, upgrading dependencies or doing repo-wide refactoring.