When is a crate to small for crates.io?


I recently wrote my first real Rust program (to generate certificate signing requests from a private key to send off to a CA), which some other people may find useful. But it currently is very small and potentially to geared to my use case. Thus, I was wondering: when is a crate (especially a binary only one) too small to publish on crates.io? Is there any consensus?

You can find the crate’s code at https://gitlab.com/MJDSys/csr_gen/tree/master. Note: I’d do some cleanup/error handling before publishing if I go that way. But its enough for me to not bother if it isn’t likely to be used by others.


I dunno, but I seem to have gotten away with boolinator.


One thing that comes to kind is this article about the realities of tiny packages (1 line to be specific).

I suppose when the utility and saved effort offered by the crate doesn’t outweigh the trust you have to place in the maintainer (or not) then it’s ‘too small’ for you. At least releases on crates.io are immutable so once it’s out that’s what it is.


What I find really cool with Rust and Cargo is how easy it is to put 90% of the functionality in lib.rs and then create a tiny wrapper that exposes a cli around it. Maybe your crate would have value as a lib too, or at least a part of it? :slight_smile:


I have one crate that’s just four functions: https://crates.io/crates/ref_slice

I find https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328 to be a very interesting comment about why JavaScript has so many small modules; with a language that’s much more strict, I don’t see this applying to Rust nearly as much, but I do think that many small pieces are better than fewer, bigger pieces.


There’s also alias and void. The former was CotW once, and the latter is extremely heavily used.


CC0 for one liners!


But that one-liner should have ten lines of doc comments :wink: