Automatically restore TypeScript starter SDK artifacts#15174
Merged
IEvangelist merged 2 commits intomicrosoft:release/13.2from Mar 12, 2026
Merged
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15174Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15174" |
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the TypeScript starter template finalization so aspire new runs restore / SDK generation through the existing guest AppHost pipeline (instead of spawning a nested CLI / npm install), ensuring .modules artifacts are immediately available after creation.
Changes:
- Inject
IAppHostProjectFactoryintoCliTemplateFactoryand use guest AppHost restore/codegen for TypeScript starter finalization. - Add CLI test coverage to validate
.modules/aspire.tsgeneration and correct channel propagation before restore. - Update E2E scenario assertions to check for generated
.modules/aspire.tsinstead of emitted.jsfiles.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/Aspire.Cli.Tests/Utils/CliTestHelper.cs | Updates test service wiring to pass IAppHostProjectFactory into CliTemplateFactory. |
| tests/Aspire.Cli.Tests/Commands/NewCommandTests.cs | Adds a focused CLI test and test doubles to validate TypeScript starter restore/codegen behavior. |
| tests/Aspire.Cli.EndToEnd.Tests/TypeScriptStarterTemplateTests.cs | Adds a scenario assertion that .modules/aspire.ts exists after aspire new. |
| src/Aspire.Cli/Templating/CliTemplateFactory.cs | Removes nested-process execution helpers and stores injected IAppHostProjectFactory. |
| src/Aspire.Cli/Templating/CliTemplateFactory.TypeScriptStarterTemplate.cs | Switches TypeScript starter finalization to call guest restore/codegen and writes channel before restore. |
| src/Aspire.Cli/Projects/IGuestAppHostSdkGenerator.cs | Introduces an internal interface to represent guest SDK generation. |
| src/Aspire.Cli/Projects/GuestAppHostProject.cs | Implements IGuestAppHostSdkGenerator for the guest AppHost handler. |
You can also share your feedback on Copilot code review. Take the survey.
src/Aspire.Cli/Templating/CliTemplateFactory.TypeScriptStarterTemplate.cs
Show resolved
Hide resolved
src/Aspire.Cli/Templating/CliTemplateFactory.TypeScriptStarterTemplate.cs
Show resolved
Hide resolved
adamint
approved these changes
Mar 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Automatically restore TypeScript starter projects as part of
aspire newso the generated.modulesSDK is available immediately after creation.Fixes #15169
This change updates the TypeScript starter template finalization flow to use the guest AppHost restore/code generation pipeline directly instead of spawning a nested CLI process. That keeps the restore behavior aligned with the existing guest project infrastructure, avoids the hanging child-process path seen in automation, and ensures the selected channel is written before restore/package resolution runs.
The implementation also keeps the generated project behavior correct by letting
aspire restoreown guest dependency installation and SDK generation rather than layering an extra template-specificnpm installstep on top. For validation, the change adds focused CLI-level coverage for the TypeScript starter restore path and updates the existing scenario assertion to verify the generated.modules/aspire.tsartifact without assuming emitted.jsfiles.Validation:
dotnet test tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj -- --filter-method "*.NewCommandWithTypeScriptStarterGeneratesSdkArtifacts" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"dotnet test tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj -- --filter-class "*.NewCommandTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"dotnet test tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj -- --filter-class "*.TypeScriptStarterTemplateTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"still fails locally in Docker terminal setup before the starter assertions run (the input device is not a TTY/ container-ready timeout), so that scenario was not revalidated end-to-end on this machine.Checklist
<remarks />and<code />elements on your triple slash comments?aspire.devissue: