{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia6aoufb4wgikxhk6ymww6qkjfwbwrbeud7pgv6itumtzfkl3cbby",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgeaerc7cjv2"
  },
  "path": "/t/alternative-to-cargo-new-templates-examples-as-build-target-templates/24047#post_13",
  "publishedAt": "2026-03-05T22:07:02.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "bushRAT:\n\n> Might be my misunderstanding, but I don't think this is a problem? Since the template wouldn't be a crate published on crates.io, the hypothetical `templates` section wouldn't need to link to a published crate, so there's no chicken and egg publishing issue. While a template is a crate, it would just be file(s) as far as Cargo and crates.io are concerned, entirely contained within the `foo` crate.\n\nSo your proposal is for there to be crates that exist but aren't part of the package or workspace that get bundled in the package? I feel like that could be confusing.\n\nbushRAT:\n\n> `cargo new` already only makes sense for brand new projects, so there's no merging functionality required.\n\nPlease re-read my original post. Making `cargo new` additive is a major part of this idea.",
  "title": "Alternative to `cargo new` templates: examples as build-target templates"
}