Thanks! What are you building on the side? Would love to know what's janky about the existing tools, that's exactly the kind of feedback that shapes what I work on next.
The kind of things I added: - Never use super:: or other relative references - always absolute. Within crate, always use the "private" paths, not the public API ones! - Make sure there are no "cycles" in the code. I.e. if you follow-click on definitions, you get somewhere deeper/sibling node, you never go around in a cycle (the only cycles that are allowed are in the same module). - Made a custom formatting tool, that always orders code in the same way: imports, constants, structs/enums, impl blocks, functions, macros, tests.
Things that would be nice: - All errors should propagate to the crate top-level errors.rs via thiserror - pub methods may not be marked as dead code, but they are dead within the monorepo (this annoys me now quite a lot now)
Probably more, just quickly from the top of my head.
The absolute paths rule and the “no cycles unless same module” rule are both clean. I like that you’re optimizing for navigation too, not just style.
The two “would be nice” points hit hard:
A single crate level errors.rs with thiserror makes big repos feel way less messy.
The “pub but dead inside the monorepo” problem is real. Rust won’t flag it because it is public, but internally it is noise and people still spend time maintaining it.
How did you build these tools? Are you using rust-analyzer APIs, HIR, syn, or something else?
Also, if you have two minutes, can you try the dashboard and tell me what feels good or annoying about the workflow? for now login with github if possible. check it out.
https://rma-dashboard.bukhari-kibuka7.workers.dev/
It’s backed by Rust Monorepo Analyzer. Right now we focus on security and code intelligence, but your hygiene rules feel like a perfect “next layer” once the core analysis is solid.