Persist `--source` from `aspire new aspire-empty` into the scaffolded project

[radical]

Persist the --source override from aspire new aspire-empty into the scaffolded project

Summary

aspire new aspire-empty --language <typescript|...> --source <X> consumes --source only during the initial scaffold restore. The scaffolded project records the version and channel in aspire.config.json but does not capture the explicit --source feed. As a result, a later aspire restore or aspire add in the same project resolves Aspire packages from the configured channel feeds — not from <X> — and silently produces a different package set (or fails outright) compared with what the scaffold restore used.

PR #17166 ships a warning at scaffold time so the user is told the override is one-shot. This issue tracks closing the gap so --source is honored across the full lifecycle of the project, or rejected up front when that's not possible.

Repro

# Hive lives outside the standard channel feeds; user wants Aspire packages from there.
aspire new aspire-empty --language typescript --name MyApp --output ./MyApp \
    --version 13.4.0-pr.NNNNN.gXXXXXXXX \
    --source /path/to/pr-hive/packages

# Scaffold succeeds.

cd MyApp
aspire add redis     # ← does NOT see /path/to/pr-hive/packages
aspire restore       # ← same: only the channel feeds in aspire.config.json

For the C# empty path the gap is even larger: --source is dropped before scaffolding runs at all (the C# template ignores inputs.Source), so the initial restore also misses the override.

Why it matters

--source is the primary lever a user has to point Aspire at a non-default package set (PR hive, local pack, internal mirror). Honoring it only on the very first command surprises anyone who runs a follow-up CLI command in the same project — the natural next step.

Options

(a) Generate nuget.config in the scaffolded project

Write a nuget.config next to aspire.config.json that:

• Adds the explicit --source as a package source.
• Adds the matching channel feeds as additional sources.
• Emits package source mapping (PSM) that pins Aspire* to the explicit source.

Pros: subsequent aspire restore/aspire add resolve packages identically to the scaffold restore. The Aspire CLI already generates this exact shape today via TemporaryNuGetConfig — the same logic can be redirected at the project directory instead of a temp file.

Cons:

• Has to interact correctly with an existing nuget.config in the parent directory tree (merge vs override).
• Credentials in a private feed (--source https://user:pat@…) probably should not be committed; need a story for that (interactive prompt? sanitize?).
• Adds a file to source control that needs to be kept in sync if the channel changes later.

(b) Warn at scaffold time (shipped in #17166)

Tell the user the override is one-shot so they can take action manually (add the feed to their own nuget.config, or move the packages to a channel feed). Lowest-friction, no design risk, but doesn't solve the underlying gap.

(c) Reject at scaffold time when the override is not also a registered channel

Fail aspire new --source <X> unless <X> matches one of the explicit channels. Highest correctness, lowest convenience — the common dogfood case (point me at this PR's hive) becomes a two-step setup.

(d) Also honor --source on the C# empty path

Today the C# empty template (WriteCSharpEmptyAppHostAsync) ignores inputs.Source entirely. Whichever direction (a)/(c) is chosen above, the C# path should match.

Suggested direction

Lean toward (a) + (d): emit nuget.config with PSM and apply it to both C# and non-C# empty templates. Pair with the existing TemplateNuGetConfigService path so the same prompt + merge behavior applies regardless of language. Handle credential-bearing source URIs by stripping userinfo from the persisted form and warning the user that auth has to be configured separately.

Out of scope

• Persisting --source for aspire init and the .NET starter templates — separate path, separate UX.
• Changing how --source interacts with --channel at restore time (already exclusive for Aspire* packages after fix(cli): keep guest AppHost restore on the selected Aspire package source #17166).

Refs

• PR fix(cli): keep guest AppHost restore on the selected Aspire package source #17166 (this PR — warning added)
• Issue aspire new aspire-empty --language typescript fails with TypeLoadException when using PR hive packages #17159 (the original bug that surfaced this)

[joperezr]

🤖 Aspire triage pass — 2026-05-19 04:15 UTC

Area: area-cli, area-templates
Kind: feature-request (follow-up gap closure)
Repro: yes-minimal — see the Repro section of the issue body
Affected version(s): 13.3.x / 13.4 in-development (latest open milestones: 13.3.x, 13.4, 13.5)
Severity: S3 — workaround exists (PR #17166 added a scaffold-time warning; users can hand-author nuget.config), but the lifecycle gap on aspire restore / aspire add is real

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: S3 with a workaround already shipped in #17166. Not a regression vs 13.2 (this is a long-standing CLI scaffolding gap), so it does not meet the servicing bar. Clear design proposal with options (a)–(d) authored by a team member — good candidate to land in the next minor rather than sit in Backlog.

Suggested owner(s): @JamesNK (score 252), backup @mitchdenny (score 34)
Evidence:

• @JamesNK merged 74 PRs in area-cli in the last 90d, including Use grid layout in DisplayMessage/DisplayError for better text wrapping #17198, Fix flaky NewCommandChannelResolutionTests by isolating home directory #17180, Fix CLI cancellation disposal race on shutdown #17179, CLI: Print app host CLI log path when connected to a running app host #17168, Improve version log messages in CLI, AppHost and dashboard #17163 — all CLI-surface work directly adjacent to aspire new / scaffolding
• @JamesNK closed 15 area-cli issues as completed in the last 180d (top closer in the area)
• @mitchdenny is the only recent merger in area-templates (2 PRs in 90d) and 2nd-place closer in area-cli (11 completed) — natural backup for the templates half of options (a)/(d)
• Issue author @radical is excluded from owner candidates
• Related context cited in the issue: PR fix(cli): keep guest AppHost restore on the selected Aspire package source #17166 (warning), issue aspire new aspire-empty --language typescript fails with TypeLoadException when using PR hive packages #17159 (originating bug)

Confidence: medium
Needs human?: no — but milestone could reasonably be Backlog instead of 13.4 depending on team priorities; flagging here rather than triage:needs-human because the recommendation is conservative (vNext, not servicing)

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[radical]

Fixed on main via #17166 (commit bd4060b7).

The PR took option (a) from this issue: TemplateNuGetConfigService.CreateOrUpdateNuGetConfigForSourceOverrideAsync writes a project-local NuGet.config that pins Aspire* to the explicit --source, preserves the resolved channel's non-Aspire fallback mappings, and stays self-contained (no parent/user/global source or credential absorption). Existing project-local NuGet.config is merged.

Wired into every scaffold path:

• C# empty — CliTemplateFactory.EmptyTemplate.cs (also closes the option-(d) C# gap this issue called out where inputs.Source was dropped).
• Non-C# empty (TypeScript, Python, Go, Java) — same file, post-scaffold.
• TS / Python / Go starters — CliTemplateFactory.{TypeScript,Python,Go}StarterTemplate.cs.
• .NET templates — DotNetTemplateFactory.cs.

The one-shot scaffold-time warning is gone (removed in the same PR). Credentialed HTTP sources (UserInfo / query / fragment) are rejected before persistence so credentials cannot leak into a committed NuGet.config.

Coverage in tests/Aspire.Cli.Tests/Templating/TemplateNuGetConfigServiceTests.cs: self-contained-config, requested-channel fallback preserved, project-local-only merge, null short-circuit.

Closing as fixed.