{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiamnuw2oq2fbqx25jsm3durvempvigdjc65y6bdthx2odncijrxrq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mg3xyg2ejer2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_1",
  "publishedAt": "2026-03-02T16:13:25.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Feature request: Cargo templates · Issue #5151 · rust-lang/cargo · GitHub"
  ],
  "textContent": "Looking for thoughts on an alternative idea to what we normally think of as templates for `cargo new` and some brainstorming on the CLI.\n\nFrom both the Cargo team and the community, there has long been an interest to having `cargo generate`-like templates in `cargo new` (Feature request: Cargo templates · Issue #5151 · rust-lang/cargo · GitHub). However, this is not trivial and has needed someone to work through problems like:\n\n  * Working out the template language to pull into our compatibility guarantees\n  * Deciding on the API surface between `cargo new` and the template, either being exhaustive or having a plan for evolving it\n  * Should we and how do we preserve the \"smart\" features like auto-inheriting\n  * How to handle updating from \"living\" templates. All of my repos have a common git merge base that is the template and this makes it easy to propagate changes out, like with lints. I couldn't live without it\n  * How to handle composition. There are project templates, and package templates and how to allow intermixing of them\n\n\n\nOn that last point, in other discussions I've realized that there is another layer of templates: API templates. These are not whole-package templates but build-target or even `mod`-specific templates. You might have a CLI template that gets you started with CLI parser, a logger, etc.You might then have a CLI test template that does end-to-end testing of your CLI, capturing SVG snapshots of the output to preserve the colors. You then might find you need to do file watching so you want to pull in a `notify` template as a `mod`.\n\nMy idea has two parts:\n\n  * `cargo new` becomes additive, allowing `cargo new --lib` when there is already a package present, adding a lib\n  * We allow specifying a package's examples as your `src/lib.rs` or `src/main.rs`. Even better if it could also be `build.rs` and `tests/foo.rs`. Amazing if we could also do `src/foo/mod.rs`.\n\n\n\nThis way you can pull in examples as you need the behavior and then start editing from there to get what you want.\n\nIf we limit this to examples you already have as dependencies, then we could look at the examples `required-features` and automatically add the features and dependencies that that activates. An example can also rely on `dev-dependencies` but we don't have a good story for detecting which are relevant and likely would have to just let those example-templates be broken.\n\nLimiting to existing dependencies makes this a bit easier to operate on. However, if we could find a way to make this also work with any package, then this would be amazing for Cargo Script. A big priority for Cargo Script is that it should be light weight enough not to need `cargo new` support. I've intentionally avoided it to help draw attention to the pain points involved in hand writing them so we can address them.\n\nHowever, if `cargo new` could give you more than\n\n\n    #!/usr/bin/env cargo\n    ---\n    package.edition = \"2024\"\n    ---\n\n    fn main() {\n    }\n\n\nand instead could give you\n\n\n    #!/usr/bin/env cargo\n    ---\n    package.edition = \"2024\"\n\n    [dependencies]\n    clap = { version = \"4.5.30\", features = [\"derive\"] }\n    ---\n\n    use clap::Parser;\n\n    #[derive(Parser)]\n    struct Cli {\n    }\n\n    fn main() {\n        let cli = Cli::parse();\n    }\n\n\nThat would be much more powerful.\n\n**However, where I'm stuck on this idea is how to design the CLI,** keeping in mind\n\n  * build-targets are additive\n  * we'd support more kinds of build targets\n  * ideally, also support mods\n  * select a dependency\n  * select the example within the dependency, helping the user choose\n  * maybe even allow this for non-dependencies\n  * align with Cargo's CLI principles\n  * fit within `cargo new`\n\n",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}