How do you organize your monorepo? | Hacker News Reader

How do you organize your monorepo?

3 pointspaulddraper4 comments

How do you organize your monorepo? I'm not asking about massive Google scale. Say, 1-15 million lines of code.

By project? By language? By technology type?

My current sketch:

    .dotfile # Configuration, IDE, etc
    project1/ # High-level project
        library1a/
        library2b/
    project2/ # High-level project
        library2a/
        library2b/
    go-common/ # Common Go libraries
    js-common/ # Common JS libraries
    tools/ # Compilers

But every time I think about this, I'm not quite satisfied. Curious what others have found successful for mid-size monorepo.

View on HN

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.

I recognize some themes from my thoughts.

I used to have `server/` `db/` `web/` `mobile/` top-level directories.

Your use of `target/` for sources (not outputs) is...unconventional for sure.

Build outputs go to `output/` ;)

Mid-sized commercial repo of scientific software, C/Python/Ruby

   bin/       # repo-level scripts
   config/    # repo-level configuration
   pkg/<pkg1> # a standalone autoconf package
   pkg/<pkg2> # :
   :
   common/    # shared code, packages symlink here

bottom level scripts install packages locally "in the right order", others create standalone .tar.gz packages (resolving symlinks) for installation elsewhere. All works rather smoothly I think, but it is medium sized, I could well see problems arising if it were 5-10 times the size (but we don't expect it to do that)

Reply on news.ycombinator.com