1. 21
  1.  

  2. 10

    You can rename lib.rs to something else using [lib] path = in Cargo.toml. If you use an editor that has “jump to file” and/or shows just the file name as tab/window title, it helps to have unique file names rather than a dozen of lib.rs. I use libfoo.rs for foo crate.

    1. 2

      Flat Is Better Than Nested

      I think most of the arguments introduced in this section is only applicable to medium-sized workspaces. With sufficient large size workspace (order of n * 100 above), a flat structure is incredibly hard to navigate and almost always require some sort of categorical re-group for easier navigation: infra, monitoring, data are common high level grouping that I have seen in some monorepo in the while.

      Cargo experience for large monorepo is not ideal at current state. I think both Bazel and Bucks have pretty good support for Rust now a day for big repos to migrate to for better support… but that might ruin the IDE experience somewhat.

      1. 3

        At that size, maybe having a single Cargo Workspace and monorepo is just not appropriate any more? Another option is to split codebase into multiple projects. Projects can treat each other like external dependencies. Sort-of like microservices architecture, but without network latency ;)

        1. 1

          Yeah, this is discussed in passing, but not emphasized. It’s important to clarify what medium-sized is: I think people tend to over-estimate the size. If you have >100 crates, you probably need a hierarchy, but 100 crates is probably over a million lines of code.

          1. 1

            And there are projects like in in the wild (let a lone inside an enterprise)…

            I.e. I think https://github.com/facebookexperimental/eden/tree/master/eden/mononoke/blobstore is a pretty good example of a sizeable monorepo (Rust, Python, CPP) and can be used for testing any claims about Large Workspaces. (note that I am pretty sure they are building the project with Buck and sanitized our all of the BUILD files)

            1. 2

              Note that the post very explicitly quantifies the range of applicability

              projects in between ten thousand and one million lines of code

              eden, with more than half a million lines of Python and more than half a million lines of Rust, is kind of beyond that.

              Rules for huge monorepos are different, if you want to learn how to organize those, you need a different article.

              1. 1

                Fair enough 🤣

                if you want to learn how to organize those, you need a different article

                It would be nice to learn what is available that’s for sure. ❤️

        2. 1

          This is all great advice, and I’m glad it’s codified so I can point people to it. Another related topic I’d like to find more case studies on is the trade-offs involved in using internal crates vs modules specifically when it comes to items like opt-in/out compile time features, compile times, binary code size, etc. etc. There are quite a few different approaches and opinions, but a good source to point people to like the OP would be excellent.

          1. 2

            The back story here is that I want to write “how to make rust project compile fast / rust-analyzer CI pipeline takes 8 minutes, and yours can be the same” for like two years now, I finally set to it on the weekend, and realized that I need to get flat workspace post out of my system first. Stay tuned! (not really — I promised steve klabnik that that post will be “the next one” half a year ago).