this would only document direct dependancies found in Cargo.toml, as well as the crate itself
Alternatives
add an optional argument to --no-deps, eg. --no-deps=indirect.
add a different option like --document-deps that allows more fine tuned control (possible options: always, never, direct)
add an option for explicitly listing all the crates to document.
Future Possibilities
option to also document deps that have items referenced in the public api of direct deps, either through function argument/return types, or through re-exports.
I think we should wait on designing this until we have public/private dependencies. I wonder if we could even make this the default behavior at that point.
For crates which set #![doc(html_root_url)] and thus still have their types link to their documentation, I actually still prefer letting them do so instead of having the extra doc clutter (at least while I have an internet connection), and keep the local docs for just the local crates. I'm thoroughly used to navigating to the correct crate's docs before searching.
Although, in fairness, since I use a shared $CARGO_TARGET_DIR for all my workspaces, my docs clutter builds up a bit more than a typical config and wouldn't actually be limited to just trans-public dependencies of the workspace, since it includes all crates documented since my last cargo clean.
I think there is some context I'm missing as I'm not understandin how my proposed idea (cargo doc only includes direct deps and their public dependencies) impacts this
Specifically, I tend to prefer using the online docs over local docs. When a type from a dependency is visible in the crate's API, it links to the local doc copy if available, or the online one at the specified #![doc(html_root_url)] otherwise.
Or maybe it was changed to default to using the docsrs root when unspecified, it's been a while since I've deliberately paid attention to that. I just recall a while ago that the attribute was required, thus why a decent number of notable crates use that attribute and have release checklists/scripts to keep the version number in it synced.
docsrs has its own setup to fixup intercrate links, and I'm trying to use cargo-docsrs locally more to keep a closer docs build environment.
Same for me: I find it faster to type docs.rs/<crate-name> in the browser than having a local cargo doc running or remembering to open a previously created one, especially when you know what crate something belongs to.
Personally I probably wouldn't use it, since I tend to know which dependency I want something from, so I'm usually using the all or nothing approach, especially since you often have to know something from re-exports or indirect dependencies to find out why something doesn't work. From that perspective it often doesn't matter much if it's a direct or indirect dependency (making an indirect dependency a direct one because you need something from it directly can be useful). But I can see how it could be useful during development.
That sounds interesting, do you have a link or rfc for that?