{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigqo2sjfsct7hp3j4oqotpgmj7l5gbpicoufwvxeq5iehl4hefqve",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgcka46shaz2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_9",
  "publishedAt": "2026-03-05T05:12:07.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Below are some thought's I've loosely grouped together. I really like the idea of official template support in Cargo, but I think there's a lot of possibilities worth exploring!\n\n# Examples (probably) Shouldn't Be Templates\n\nI don't think we want to directly pull examples from existing crates as templates. A larger crate, like `bevy` has many excellent examples, but the `dev-dependencies` section is _massive_ in order to accommodate all the different kinds of examples it showcases. I feel like you'd want an explicit `template` item to pull from, which would just be a crate (either a single-file script or a more typical crate). The benefit of the new frontmatter system is you could now have single-file templates, which would just look identical to examples anyway. The key difference is they're explicitly a separate crate, so they have their own dependencies, enabled features, etc.\n\nSince a `template` section would be new, it could also have explicit support for a default. This would let a crate like `clap` provide a template that fits most users, and then some extra templates for useful niches. This would also solve having template kinds that go beyond the currently understood set of tests, benchmarks, libraries, etc. For example, a `mod` template could still include a frontmatter that gets merged with the target crate's manifest, and then it's body would be a new module.\n\n# Macros?\n\nIf templates are meant to include extending an existing project, not just creating a new one, I feel like we need either a build script or a proc-macro to handle merging a template into a project. Take `tokio` and `clap` as examples. They each could have templates for a new binary project, and ideally you could slap `tokio` onto an existing project and it would handle taking the contents of your existing `main` function and placing them into the new `async` version for you. This probably can't be done by Cargo since it's far too contextual, but I think either a `merge.rs` or a merge proc-macro could do it.\n\n# `--interactive`\n\nI do think a TUI more like `npm init` would be useful, especially for new users. For one thing, it could give you an option to search for a template from `crates.io`, select features and dependencies, etc. I imagine you could add a `--interactive/-I` switch to turn this on (in order to preserve the current fast non-interactive command).",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}