pksunkara
Update workspace.members when create
Is there a way to add newly created members to the root Cargo.toml file under workspace.members?
Currently I add it manually whenever I create a new member project.
I would imagine that cargo ws create would automatically add the new project to the members list - but it doesn't.
Or even better if there was a separate command cargo ws update which finds all the dangling subprojects and either adds them to workspace.members or workspace.exclude.
https://github.com/pksunkara/cargo-workspaces/blob/772e6252fb3bb126796f9196fea5202337dfab9e/cargo-workspaces/src/create.rs#L76. Needs programmatic TOML editor first.
the crate name should be inferred from the path - it's annoying to specify it twice.
Yeah I kindof thought this was the entire point of cargo ws was to be able to create new crates in the workspace...
There is cargo sort command, that parses TOMLs and sorts dependencies and other fields. Maybe use their code for parsing workspace manifest?
It uses toml_edit underneath which (even with the rewrite) doesn't keep the formatting.
Maybe we can do it in a clippy --fix way: warn user, that the formatting can be broken and deny to modify Cargo.toml unless it is backed up in git?
The entire reason I installed cargo-workspaces was because cargo doesn't automatically add a new crate to the workspace, and it doesn't even do it. This is a much-needed feature, it's annoying to manually go and add it.
Is there an example of where formatting the Cargo.toml changes the underlying data stored? Like if it's parsed, where the formatting would change any of the values. If not, I don't think formatting should be of any concern.
Now that we have cargo add, that seems to keep the formatting? So I'd assume cargo-workspaces can use the same?
I'd definitely be stoked to see this added. I similarly would consider defaulting to --vcs none for cargo ws create, if I'm right in thinking that most folks are using this for managing workspace monorepos.
It would really round things out if cargo ws init then accepted the --vcs parameter as well and generated the appropriate .gitignore equivalent, the same way that cargo create does. No option and assuming Git (and .gitignore) would be a start as well.
if I'm right in thinking that most folks are using this for managing workspace monorepos.
the crate is called "cargo-workspaces" it'd be pretty cool if it could, idk, manage workspaces
Workspaces without a doubt, though I suppose someone out there might be using it for managing a workspace where each project is a Git submodule. Still, without even considering the mention of Lerna at the top of the readme, I'd say assuming most folks are using a monorepo is... a safe bet.