{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibfz7ehxim6vwxtlvmvjtttpwcgirvifqhehon3ou6ooydhbqldnm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgfpdmzqjad2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_15",
  "publishedAt": "2026-03-06T15:14:34.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "bushRAT:\n\n> I mean, is it any different to tests, benchmarks, or examples as-is? `docs.rs` will include snippets of code from examples in documentation, but examples aren't themselves published to crates.io, so there is definitely precedent here.\n\nI'm looking at it from the users perspective. They put `Cargo,toml`s down that are \"part of their package\" but `cargo check --workspace` doesn't build them?\n\nbushRAT:\n\n> Sorry I think I worded that badly, what I meant was for an MVP on templates we don't need to consider the additive functionality yet, that can be added after there's a mechanism for templates. Whereas, I don't think you can make `cargo new` additive without templates (aside from just creating empty files I guess?)\n\nI think there is a major gap between our thought processes and/or understandings on this.\n\nIn my mind, there are distinct needs between project, package, and API templates and if we want a single solution to cover their needs then we would need to do a serious analysis of all of them to make sure we don't back ourselves into a corner. My suspicion is that there are major divergences in needs. Part of the intent of this proposal is to remove a lot of the complexity that comes with handling project and package templates by focusing in on API templates which have a much smaller feature set and intersections with existing dynamic behavior in `cargo new` that we would likely want to keep. This feels like it fits well within `cargo new`s existing behavior and will compose with project or package templates just as well as the existing `cargo new` behavior.\n\nThe whole proposal is about having additive templates in `cargo new` that aren't empty files. To say you we can't do it requires some clearly articulated reasoning to back such a statement.",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}