Should I split my multi-crate project into separate repos?


I have a project that spans a couple of (mostly) orthogonal crates. Currently, these are all in the same Github repo, which has made it easy for me to develop the main functionality of them all but also has a few drawbacks.

Namely there’s only the 1 build script. This means if there are any cross-crate issues they’re picked up right away and are easy to solve, but also lumps the build of independent crates together. So while some crates support stable, this isn’t obvious from the build script because it only runs on nightly.

Is it worth the extra effort and complexity to let the crates scale in their own right in their own repos; with their own build, test coverages, doc automation, issues etc. Or can this all be achieved while still keeping everything together?

Compilation issues in a multi-crate project

You can put sub-crates in subdirectories of your crate root and link them as dependencies in your Cargo.toml IIRC.

I struggle to remember where I’ve seen this, however.


One example, regex depends on regex-syntax.

However from the original post, it sounds like the crates are already separated as distinct crates in distinct directories in a single repository.

@KodrAus, are you comfortable linking to the project so we can see the structure you’re asking about more specifically?


Sure, the project is here.

Each folder in the root is a distinct crate, except for benches. The only hard dependency is that types depends on macros. But the crates are designed to be used together too, like hyper + macros + types.

I haven’t really built an open source project before, so I’m not sure how to get the most out of repo / CI granularity.


For reference, I’ve found building multiple projects in a single repo a bit nicer since using env in my .travis.yml:

  - CRATE="codegen"
  - CRATE="hyper"
  - CRATE="hyper/codegen"
  - CRATE="hyper/samples"
  - CRATE="macros"
  - CRATE="types"
  - cd $CRATE
  - cargo test -v
  - cargo bench -v
  - cargo doc

That at least solves the problem of not getting much visibility over the CI for each crate individually.