{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicy5eur24c7vylk36r6xohfhjibf56qvtc2o5qjckolsg5q4tuibu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgcvdyzniv52"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_10",
  "publishedAt": "2026-03-05T12:06:56.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "I like the idea of splitting templates and making them incremental. Tauri and Bevy have lots of optional functionality. Setting everything upfront requires complex interactive generators, and is too much for a new user anyway. These projects would benefit from adding one plugin at a time.\n\nTrying to use targets of one package with unique per-target dependencies is another case where targets in a package want to be more like packages within a workspace. For discoverability in Cargo you'd also want to have descriptions for them, which the package has, but targets don't.\n\nPerhaps this is where publishing of workspaces to crates.io would help? Templates could be implemented as packages, with clearly defined dependencies (dev too), and their own features.\n\nMaybe even `build.rs` equivalent for integration into an existing project? Bevy needs to add plugins to initialization stage, register resources and types for reflection, etc. Tauri similarly has an app init boilerplate to update, as well as a bunch of JSON files with per-plugin permissions to set.",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}