Skip to content

Improve aspire doctor TypeScript AppHost diagnostics across package managers#17214

Merged
IEvangelist merged 3 commits into
mainfrom
dapine/aspire-doctor-ts-diagnostics
May 19, 2026
Merged

Improve aspire doctor TypeScript AppHost diagnostics across package managers#17214
IEvangelist merged 3 commits into
mainfrom
dapine/aspire-doctor-ts-diagnostics

Conversation

@IEvangelist
Copy link
Copy Markdown
Member

@IEvangelist IEvangelist commented May 18, 2026 •
edited
Loading

Description

Closes #17032 (part of #16961).

Two changes to aspire doctor's TypeScript AppHost diagnostics, each targeting a different package-manager scenario.

1. Surface Yarn Classic as a real diagnostic (product change)

TypeScriptAppHostToolchainResolver.Resolve throws InvalidOperationException when it sees Yarn Classic (either "packageManager": "[email protected]" in package.json or a yarn.lock containing the # yarn lockfile v1 marker). That exception was bubbling out of TypeScriptAppHostToolingCheck.CheckAsync uncaught; EnvironmentChecker.CheckAllAsync would swallow it at Debug log level and continue. The net effect for users: aspire doctor produced no output at all about the TypeScript AppHost in a Yarn Classic workspace — neither Pass nor Fail.

TypeScriptAppHostToolingCheck.CheckAsync now catches that InvalidOperationException and emits a structured Fail result:

Field Value
Name typescript-apphost-yarn-classic
Status Fail
Category environment
Message TypeScript AppHost does not support Yarn Classic.
Details The resolver's user-facing exception text — includes the specific offending packageManager value or yarn.lock path
Fix Upgrade to Yarn 4 or later, or switch to npm, pnpm, or Bun, then rerun 'aspire doctor'.
Link https://yarnpkg.com/getting-started/install

Two new tests in TypeScriptAppHostToolingCheckTests cover both detection signals (the packageManager field and the yarn.lock v1 marker).

2. Expand existing pass/fail coverage to all four package managers (test change)

tests/Aspire.Cli.Tests/Commands/TypeScriptAppHostToolingCheckTests.cs:

  • CheckAsync_ReturnsPass_WhenConfiguredToolchainIsAvailable is now a [Theory] parameterized across Npm, Pnpm, Yarn, and Bun.
  • CheckAsync_ReturnsFail_WhenConfiguredToolchainIsMissing is now a [Theory] parameterized across Npm, Pnpm, Yarn, and Bun. Asserts Status=Fail, Name=typescript-apphost-{command}, Link from CommandPathResolver, Fix = "Install {displayName} tooling and rerun 'aspire doctor'.", and Details from GetMissingCommandMessage. The Npm case correctly produces two Fail entries — one for npm, one for npx — because GetRequiredCommands(Npm) = ["npm", "npx"].
  • New CheckAsync_ReturnsFailOnlyForMissingNpmCommand_WhenTheOtherIsPresent theory covers the partial-npm cases (npm present / npx missing, and vice versa).
  • CheckAsync_Skips_WhenNoTypeScriptAppHostExists is unchanged.

Toolchain enum values are passed via nameof(TypeScriptAppHostToolchain.X) and parsed inside the test method to avoid putting an internal enum in a public test method signature.

Verification

.\dotnet.cmd build .\tests\Aspire.Cli.Tests\Aspire.Cli.Tests.csproj /p:SkipNativeBuild=true
.\dotnet.cmd test  .\tests\Aspire.Cli.Tests\Aspire.Cli.Tests.csproj --no-build -- `
  --filter-class "*.TypeScriptAppHostToolingCheckTests" `
  --filter-class "*.TypeScriptAppHostToolchainResolverTests" `
  --filter-class "*.CommandPathResolverTests" `
  --filter-class "*.DoctorCommandTests" `
  --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"

Build: clean (0 warnings, 0 errors). Tests: 58/58 passing locally.

Checklist

Test TypeScriptAppHostToolingCheck across all package managers
e5a3f85 
Expands TypeScriptAppHostToolingCheckTests to cover npm, pnpm, Yarn, and Bun
(previously only Bun was tested). For each toolchain, verifies that:

- A Pass result is returned when all required CLIs are on PATH, with the
  result Message naming every required command.
- A Fail result is returned for each missing CLI, carrying the toolchain's
  installation link from CommandPathResolver, the Fix string that names the
  installation display name, and Details produced by GetMissingCommandMessage.

Also adds a dedicated theory for the npm toolchain (the only toolchain that
requires two CLIs) covering npm-missing-only and npx-missing-only scenarios.

Closes #17032

Co-authored-by: Copilot <[email protected]>
Copilot AI review requested due to automatic review settings May 18, 2026 16:18
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 18, 2026 •
edited
Loading

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17214

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17214"

Copilot AI reviewed May 18, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR expands TypeScriptAppHostToolingCheckTests so aspire doctor TypeScript AppHost tooling diagnostics are exercised across npm, Bun, Yarn, and pnpm.

Changes:

  • Converts the existing pass/fail tooling checks into package-manager theories.
  • Adds validation for failure status, category, links, fixes, details, and per-command result names.
  • Adds npm-specific partial-missing coverage for npm vs npx.

@IEvangelist IEvangelist changed the title Test TypeScriptAppHostToolingCheck across all package managers Add aspire doctor 'Polyglot AppHost' category and expand TS AppHost tooling tests May 18, 2026
davidfowl
davidfowl reviewed May 18, 2026
View reviewed changes
Comment thread src/Aspire.Cli/Commands/DoctorCommand.cs Outdated
davidfowl
davidfowl reviewed May 18, 2026
View reviewed changes
Comment thread src/Aspire.Cli/Utils/EnvironmentChecker/TypeScriptAppHostToolingCheck.cs Outdated
@IEvangelist IEvangelist marked this pull request as draft May 18, 2026 16:44
@github-actions github-actions Bot mentioned this pull request May 18, 2026
Open
@IEvangelist IEvangelist force-pushed the dapine/aspire-doctor-ts-diagnostics branch from ab5e3e8 to e5a3f85 Compare May 18, 2026 17:53
@IEvangelist IEvangelist changed the title Add aspire doctor 'Polyglot AppHost' category and expand TS AppHost tooling tests Test TypeScriptAppHostToolingCheck across all package managers May 18, 2026
Surface Yarn Classic as a diagnostic in 'aspire doctor'
ec059e8 
Previously, when a TypeScript AppHost workspace used Yarn Classic ([email protected] or a yarn.lock with the v1 marker), TypeScriptAppHostToolchainResolver.Resolve would throw InvalidOperationException, the exception would bubble out of TypeScriptAppHostToolingCheck.CheckAsync uncaught, and EnvironmentChecker.CheckAllAsync would silently swallow it at Debug level. Net result: 'aspire doctor' produced no TypeScript AppHost output at all for these workspaces.

This change catches the InvalidOperationException in TypeScriptAppHostToolingCheck and emits a Fail result instead, including:
- Name: typescript-apphost-yarn-classic
- Status: Fail
- Message: 'TypeScript AppHost does not support Yarn Classic.'
- Details: the resolver's user-facing exception text (mentions the specific offending packageManager value or lockfile path, depending on which signal triggered detection)
- Fix: 'Upgrade to Yarn 4 or later, or switch to npm, pnpm, or Bun, then rerun aspire doctor.'
- Link: https://yarnpkg.com/getting-started/install

Adds two tests in TypeScriptAppHostToolingCheckTests covering both detection signals (packageManager field and yarn.lock with v1 marker).

Co-authored-by: Copilot <[email protected]>
@IEvangelist IEvangelist changed the title Test TypeScriptAppHostToolingCheck across all package managers Improve aspire doctor TypeScript AppHost diagnostics across package managers May 18, 2026
Narrow Yarn Classic catch to a dedicated exception type
c1d540e 
The previous commit caught plain InvalidOperationException from TypeScriptAppHostToolchainResolver.Resolve and treated every IOE as a Yarn Classic diagnostic. That binding is implicit: if a future contributor adds any other 'throw new InvalidOperationException(...)' inside Resolve (or anything it calls), the doctor check would silently surface it as 'TypeScript AppHost does not support Yarn Classic' with a Yarn install link - misleading users about the actual problem.

Introduces YarnClassicNotSupportedException : InvalidOperationException, has the resolver throw that specific type from CreateYarnClassicNotSupportedException, and narrows the catch in TypeScriptAppHostToolingCheck.CheckAsync to the new type. Subclassing InvalidOperationException preserves the resolver's existing public throw contract (callers catching IOE still work).

Updates the three existing 'Resolve_When*Yarn*Classic*_Throws' tests in TypeScriptAppHostToolchainResolverTests to assert on the specific exception type.

Co-authored-by: Copilot <[email protected]>
@IEvangelist
Copy link
Copy Markdown
Member Author

IEvangelist commented May 18, 2026

PR Testing Report — PR #17214

PR Information

  • PR Number: #17214
  • Title: Improve aspire doctor TypeScript AppHost diagnostics across package managers
  • Author: @IEvangelist
  • Branch: dapine/aspire-doctor-ts-diagnostics
  • Head Commit: c1d540ed9d55009a3792c17e04d3a229e870109d
  • State: Draft, OPEN, MERGEABLE
  • Tested: 2026-05-18 (Windows 11 PowerShell, local mode)

CLI Version Verification

Field Value
Expected (PR head SHA short) c1d540ed
Installed aspire --version 13.4.0-pr.17214.gc1d540ed
Status ✅ Verified

Installed from PR comment dogfood instructions via iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17214" after CI workflow run 26052143080 finished publishing the win-x64 archive.

Changes Analyzed

Files changed (4 prod, 2 test):

  • src/Aspire.Cli/Projects/TypeScriptAppHostToolchainResolver.cs — throw site swap from plain InvalidOperationException → YarnClassicNotSupportedException
  • src/Aspire.Cli/Projects/YarnClassicNotSupportedException.cs — new sealed subclass : InvalidOperationException (preserves IOE call-site contract)
  • src/Aspire.Cli/Utils/EnvironmentChecker/TypeScriptAppHostToolingCheck.cs — wrap Resolve() in try { … } catch (YarnClassicNotSupportedException) { … }, emit structured Fail diagnostic with Name=typescript-apphost-yarn-classic
  • tests/Aspire.Cli.Tests/Commands/TypeScriptAppHostToolingCheckTests.cs — parametrize across Npm/Bun/Yarn/Pnpm + new Yarn Classic tests (both detection paths)
  • tests/Aspire.Cli.Tests/Projects/TypeScriptAppHostToolchainResolverTests.cs — assert new exception type

Change categories:

  • ☑ CLI changes (env checker + resolver)
  • ☐ Hosting integration changes
  • ☐ Dashboard changes
  • ☐ Template changes
  • ☐ Client/Component changes
  • ☑ Test changes (parametrization + Yarn Classic coverage)

Test Scenarios Executed

All scenarios use a fresh synthetic TypeScript AppHost (apphost.ts + package.json) in a temp subdirectory, then run aspire doctor --non-interactive --nologo --format Json from that directory.

Scenario 1 — Smoke: aspire doctor --help

Objective: Confirm the doctor command surface is intact and supports --format Json.
Status: ✅ Passed

Usage:
  aspire doctor [options]
Options:
  --format <Json|Table>   Output format (Table or Json)
  …

Scenario 2 — Yarn Classic via packageManager: [email protected]

Objective: Verify the new structured Fail diagnostic when package.json declares Yarn 1.x via the packageManager field.

Fixture:

{ "name": "apphost", "packageManager": "[email protected]" }

Status: ✅ Passed

Doctor JSON output (relevant check):

{
  "category": "environment",
  "name": "typescript-apphost-yarn-classic",
  "status": "fail",
  "message": "TypeScript AppHost does not support Yarn Classic.",
  "fix": "Upgrade to Yarn 4 or later, or switch to npm, pnpm, or Bun, then rerun 'aspire doctor'.",
  "link": "https://yarnpkg.com/getting-started/install",
  "details": "Yarn Classic is not supported for TypeScript AppHosts. Upgrade '[email protected]' in …\\scenario-2-yarn-classic-pm\\package.json to Yarn 4 or later, or use npm, pnpm, or Bun.",
  "metadata": {
    "language": "typescript/nodejs",
    "appHostPath": "…\\scenario-2-yarn-classic-pm\\apphost.ts"
  }
}

All structured fields present and accurate: Name, Status, Category, Message, Fix, Link, Details, Metadata.

Scenario 3 — Yarn Classic via yarn.lock v1 marker

Objective: Verify detection of the second Yarn Classic path — a yarn.lock containing the # yarn lockfile v1 marker when package.json does not declare packageManager.

Fixture:

  • package.json → { "name": "apphost" }
  • yarn.lock → # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.\n# yarn lockfile v1\n

Status: ✅ Passed

Doctor JSON output (relevant check):

{
  "category": "environment",
  "name": "typescript-apphost-yarn-classic",
  "status": "fail",
  "message": "TypeScript AppHost does not support Yarn Classic.",
  "fix": "Upgrade to Yarn 4 or later, or switch to npm, pnpm, or Bun, then rerun 'aspire doctor'.",
  "link": "https://yarnpkg.com/getting-started/install",
  "details": "Yarn Classic is not supported for TypeScript AppHosts. Upgrade the Yarn lockfile at …\\scenario-3-yarn-classic-lock\\yarn.lock to Yarn 4 or later, or use npm, pnpm, or Bun.",
  "metadata": {
    "language": "typescript/nodejs",
    "appHostPath": "…\\scenario-3-yarn-classic-lock\\apphost.ts"
  }
}

details correctly references the yarn.lock file (not the package.json) — the two detection paths produce different, accurate details text.

Scenario 4 — No false positive on modern yarn.lock

Objective: Verify a Yarn 4 yarn.lock (no # yarn lockfile v1 marker) does not trip the Yarn Classic diagnostic.

Fixture:

  • package.json → { "name": "apphost", "packageManager": "[email protected]" }
  • yarn.lock → contains # This file is generated by running "yarn install"… + __metadata: version: 8

Status: ✅ Passed

Doctor JSON output (relevant check):

{
  "category": "environment",
  "name": "typescript-apphost-tools",
  "status": "pass",
  "message": "TypeScript AppHost tooling found (yarn).",
  "metadata": {
    "language": "typescript/nodejs",
    "toolchain": "yarn",
    "appHostPath": "…\\scenario-4-yarn-modern\\apphost.ts"
  }
}

Summary: P=5 W=0 F=0. No typescript-apphost-yarn-classic entry; resolver correctly classified the project as Yarn (modern) and the tooling check passed because yarn is on PATH.

Scenario 5 — Bun toolchain with bun absent from PATH

Objective: Verify the existing missing-toolchain Fail path is not broken by the new Yarn Classic catch — i.e., a missing-tool Fail must surface as typescript-apphost-<command>, not as Yarn Classic.

Fixture:

  • package.json → { "name": "apphost", "packageManager": "[email protected]" }
  • (no bun binary on PATH)

Status: ✅ Passed

Doctor JSON output (relevant check):

{
  "category": "environment",
  "name": "typescript-apphost-bun",
  "status": "fail",
  "message": "TypeScript AppHost requires 'bun'.",
  "fix": "Install Bun tooling and rerun 'aspire doctor'.",
  "link": "https://bun.sh/docs/installation",
  "details": "bun is not installed or not found in PATH. Please install Bun and try again.",
  "metadata": {
    "language": "typescript/nodejs",
    "toolchain": "bun",
    "command": "bun"
  }
}

Confirms the catch in CheckAsync is correctly scoped to YarnClassicNotSupportedException; other Fail paths (missing commands) flow through unchanged.

Scenario 6 — npm tooling baseline

Objective: Baseline confirmation that the existing happy path is unchanged.

Fixture:

  • package.json → { "name": "apphost", "packageManager": "[email protected]" }
  • npm and npx on PATH

Status: ✅ Passed

Doctor JSON output (relevant check):

{
  "category": "environment",
  "name": "typescript-apphost-tools",
  "status": "pass",
  "message": "TypeScript AppHost tooling found (npm, npx).",
  "metadata": {
    "language": "typescript/nodejs",
    "toolchain": "npm",
    "appHostPath": "…\\scenario-6-npm-pass\\apphost.ts"
  }
}

Summary: P=5 W=0 F=0.

Summary

# Scenario Status Notes
1 doctor --help smoke ✅ Passed --format Json supported
2 Yarn Classic via packageManager: [email protected] ✅ Passed Fail diagnostic correctly emitted; details reference package.json
3 Yarn Classic via yarn.lock v1 marker ✅ Passed Fail diagnostic correctly emitted; details reference yarn.lock
4 Modern yarn.lock (Yarn 4 metadata) ✅ Passed No false positive; tooling check passes
5 Bun toolchain, bun absent ✅ Passed Existing missing-tool path intact; catch is properly scoped
6 npm tooling baseline ✅ Passed Existing pass path intact

Overall Result

✅ PR VERIFIED

All 6 scenarios passed. The new aspire doctor Yarn Classic diagnostic:

  1. Correctly identifies both detection paths (packageManager field and yarn.lock v1 marker) and emits a fully-structured Fail result with Name, Status, Category, Message, Fix, Link, Details, Metadata.
  2. Does not produce false positives for modern Yarn 4 projects without the v1 lockfile marker.
  3. Does not break adjacent diagnostics — missing-toolchain Fails (e.g., bun absent) still surface as typescript-apphost-<command> rather than being misclassified.
  4. Is properly scoped via the dedicated exception type (YarnClassicNotSupportedException : InvalidOperationException), confirmed by Scenario 5 not surfacing Yarn Classic for an unrelated Fail.

Recommendations

  • Behavior matches the PR description and test coverage. No regressions observed.
  • The PR is currently in draft; once davidfowl's open file-level "nah" review on TypeScriptAppHostToolingCheck.cs is addressed (the new YarnClassicNotSupportedException already resolves the brittle-catch concern raised in code review), this looks ready to ship.

Artifacts

Captured under each scenario-N-* subdirectory of the test workspace:

  • doctor.json — raw doctor JSON output per scenario
  • Synthetic apphost.ts + package.json (+ optional yarn.lock) fixtures

Test workspace: C:\Users\dapine\AppData\Local\Temp\aspire-pr-test-fa5c94cbf40f4cdf8827b2e739b88b8b (will be cleaned up).

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 18, 2026

❓ CLI E2E Tests unknown — 86 passed, 0 failed, 1 unknown (commit c1d540e)

View all recordings
Status Test Recording
✅ AddPackageInteractiveWhileAppHostRunningDetached ✅ ▶️ View recording
✅ AddPackageWhileAppHostRunningDetached ✅ ▶️ View recording
✅ AgentCommands_AllHelpOutputs_AreCorrect ✅ ▶️ View recording
✅ AgentInitCommand_DefaultSelection_InstallsDefaultSkills ✅ ▶️ View recording
✅ AgentInitCommand_MigratesDeprecatedConfig ✅ ▶️ View recording
✅ AspireAddPackageVersionToDirectoryPackagesProps ✅ ▶️ View recording
✅ AspireInitSingleFileAppHostRunsViaDotnetRunAppHost ✅ ▶️ View recording
✅ AspireInitWithExistingAppHostDirRecreatesMissingNuGetConfigAndPreservesFiles ✅ ▶️ View recording
❔ AspireInitWithSolutionFileGeneratesAppHostThatBuildsAgainstChannelHive ❔ ▶️ View recording
✅ AspireUpdateRemovesAppHostPackageVersionFromDirectoryPackagesProps ✅ ▶️ View recording
✅ AspireUpdateRemovesOrphanAppHostPackageVersionWhenSdkAlreadyCurrent ✅ ▶️ View recording
✅ Banner_DisplayedOnFirstRun ✅ ▶️ View recording
✅ Banner_DisplayedWithExplicitFlag ✅ ▶️ View recording
✅ Banner_NotDisplayedWithNoLogoFlag ✅ ▶️ View recording
✅ CertificatesClean_RemovesCertificates ✅ ▶️ View recording
✅ CertificatesTrust_WithNoCert_CreatesAndTrustsCertificate ✅ ▶️ View recording
✅ CertificatesTrust_WithUntrustedCert_TrustsCertificate ✅ ▶️ View recording
✅ ConfigSetGet_CreatesNestedJsonFormat ✅ ▶️ View recording
✅ CreateAndRunAspireStarterProject ✅ ▶️ View recording
✅ CreateAndRunAspireStarterProjectWithBundle ✅ ▶️ View recording
✅ CreateAndRunEmptyAppHostProject ✅ ▶️ View recording
✅ CreateAndRunJavaEmptyAppHostProject ✅ ▶️ View recording
✅ CreateAndRunJsReactProject ✅ ▶️ View recording
✅ CreateAndRunPythonReactProject ✅ ▶️ View recording
✅ CreateAndRunTypeScriptEmptyAppHostProject ✅ ▶️ View recording
✅ CreateAndRunTypeScriptStarterProject ✅ ▶️ View recording
✅ CreateJavaAppHostWithViteApp ✅ ▶️ View recording
✅ CreateTypeScriptAppHostWithViteApp_UsesConfiguredToolchain ✅ ▶️ View recording
✅ DashboardRunWithOtelTracesReturnsNoTraces ✅ ▶️ View recording
✅ DeployK8sBasicApiService ✅ ▶️ View recording
✅ DeployK8sWithExternalHelmChart ✅ ▶️ View recording
✅ DeployK8sWithGarnet ✅ ▶️ View recording
✅ DeployK8sWithMongoDB ✅ ▶️ View recording
✅ DeployK8sWithMySql ✅ ▶️ View recording
✅ DeployK8sWithPostgres ✅ ▶️ View recording
✅ DeployK8sWithRabbitMQ ✅ ▶️ View recording
✅ DeployK8sWithRedis ✅ ▶️ View recording
✅ DeployK8sWithSqlServer ✅ ▶️ View recording
✅ DeployK8sWithValkey ✅ ▶️ View recording
✅ DeployTypeScriptAppToKubernetes ✅ ▶️ View recording
✅ DescribeCommandResolvesReplicaNames ✅ ▶️ View recording
✅ DescribeCommandShowsRunningResources ✅ ▶️ View recording
✅ DetachFormatJsonProducesValidJson ✅ ▶️ View recording
✅ DetachFormatJsonProducesValidJsonWhenRestartingExistingInstance ✅ ▶️ View recording
✅ DoListStepsShowsPipelineSteps ✅ ▶️ View recording
✅ DocsCommand_RendersInteractiveMarkdownFromLocalSource ✅ ▶️ View recording
✅ DoctorCommand_DetectsDeprecatedAgentConfig ✅ ▶️ View recording
✅ DoctorCommand_TypeScriptAppHostReportsMissingConfiguredToolchain ✅ ▶️ View recording
✅ DoctorCommand_WithSslCertDir_ShowsTrusted ✅ ▶️ View recording
✅ DoctorCommand_WithoutSslCertDir_ShowsPartiallyTrusted ✅ ▶️ View recording
✅ GlobalMigration_HandlesCommentsAndTrailingCommas ✅ ▶️ View recording
✅ GlobalMigration_HandlesMalformedLegacyJson ✅ ▶️ View recording
✅ GlobalMigration_PreservesAllValueTypes ✅ ▶️ View recording
✅ GlobalMigration_SkipsWhenNewConfigExists ✅ ▶️ View recording
✅ GlobalSettings_MigratedFromLegacyFormat ✅ ▶️ View recording
✅ InitTypeScriptAppHost_AugmentsExistingViteRepoAtRoot ✅ ▶️ View recording
✅ InteractiveCSharpInitCreatesExpectedFiles ✅ ▶️ View recording
✅ InvalidAppHostPathWithComments_IsHealedOnRun ✅ ▶️ View recording
✅ LatestCliCanStartStableChannelAppHost ✅ ▶️ View recording
✅ LatestCliCanStartStableChannelTypeScriptAppHost ✅ ▶️ View recording
✅ LegacySettingsMigration_AdjustsRelativeAppHostPath ✅ ▶️ View recording
✅ LogLevelTrace_ProducesTraceEntriesInCliLogFile ✅ ▶️ View recording
✅ LogsCommandShowsResourceLogs ✅ ▶️ View recording
✅ OtelLogsReturnsStructuredLogsFromStarterApp ✅ ▶️ View recording
✅ OtelLogsReturnsStructuredLogsFromStarterAppIsolated ✅ ▶️ View recording
✅ PsCommandListsRunningAppHost ✅ ▶️ View recording
✅ PsFormatJsonOutputsOnlyJsonToStdout ✅ ▶️ View recording
✅ PublishWithConfigureEnvFileUpdatesEnvOutput ✅ ▶️ View recording
✅ PublishWithDockerComposeServiceCallbackSucceeds ✅ ▶️ View recording
✅ PublishWithoutOutputPathUsesAppHostDirectoryDefault ✅ ▶️ View recording
✅ ResourceCommand_FailedExecution_DisplaysAppHostLogPathAndLogContainsEntries ✅ ▶️ View recording
✅ ResourceCommand_FailsWhenInteractionServiceIsRequired ✅ ▶️ View recording
✅ ResourceCommand_SetAndDeleteParameterUpdatesDescribeOutput ✅ ▶️ View recording
✅ RestoreGeneratesSdkFiles ✅ ▶️ View recording
✅ RestoreGeneratesSdkFiles_WithConfiguredToolchain ✅ ▶️ View recording
✅ RestoreRefreshesGeneratedSdkAfterAddingIntegration ✅ ▶️ View recording
✅ RestoreSupportsConfigOnlyHelperPackageAndCrossPackageTypes ✅ ▶️ View recording
✅ RunFromParentDirectory_UsesExistingConfigNearAppHost ✅ ▶️ View recording
✅ SecretCrudOnDotNetAppHost ✅ ▶️ View recording
✅ SecretCrudOnTypeScriptAppHost ✅ ▶️ View recording
✅ StagingChannel_ConfigureAndVerifySettings_ThenSwitchChannels ✅ ▶️ View recording
✅ StartAndWaitForTypeScriptSqlServerAppHostWithNativeAssets ✅ ▶️ View recording
✅ StopAllAppHostsFromAppHostDirectory ✅ ▶️ View recording
✅ StopNonInteractiveSingleAppHost ✅ ▶️ View recording
✅ StopWithNoRunningAppHostExitsSuccessfully ✅ ▶️ View recording
✅ UnAwaitedChainsCompileWithAutoResolvePromises ✅ ▶️ View recording
✅ UpdateProjectChannelToStable_TypeScript_PicksUpStablePackages ✅ ▶️ View recording

📹 Recordings uploaded automatically from CI run #26052143080

@IEvangelist IEvangelist marked this pull request as ready for review May 18, 2026 19:52
@IEvangelist IEvangelist merged commit fedcb9d into main May 19, 2026
588 of 591 checks passed
@microsoft-github-policy-service microsoft-github-policy-service Bot added this to the 13.4 milestone May 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot Copilot left review comments

@davidfowl davidfowl davidfowl approved these changes

@sebastienros sebastienros sebastienros approved these changes

@mitchdenny mitchdenny Awaiting requested review from mitchdenny mitchdenny is a code owner

@JamesNK JamesNK Awaiting requested review from JamesNK JamesNK is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

13.4

Development

Successfully merging this pull request may close these issues.

Validate aspire doctor diagnostics for TypeScript AppHost package managers

5 participants

@IEvangelist @davidfowl @sebastienros