#AskFedi: I have a Rust question. My usual approach to developing a collection of modular (but related) libraries in JS is:
1. Start with one monolithic package, in which everything is developed initially.
2. But opportunistically minimize assumptions between parts of the package, so that internally it is already mostly modular.
3. Spend some time figuring out reasonable APIs for the remaining, more-difficult-to-modularize cases.
4. Eventually split out all the internal parts into separate libraries/packages and publish them independently, so that users can select only the parts that they need, and easily combine it with third-party libraries.
What would a good workflow for this look like in Rust, especially in terms of internal crate layout (in step 1) so that it's easy to split out into separate crates later, but also in terms of tools to use?
I do not use monorepos, each crate will have its own repository in the end. Also, contributors must be able to use standard Cargo commands to manage the different crates, so no 'wrapper scripts' or third-party tools (unless they can be made to run from within Cargo).
@joepie91 Such granularity in packaging is something I do not recognize from Rust. Packaging as a monolith is more common.
If you have modules for interoperability with other, optional, packages you could solve this with Cargo features?