feat(cli): warn of non-existent stacks in cdk destroy

[go-to-k]

Fixes aws/aws-cdk#32836, aws/aws-cdk#32545, aws/aws-cdk#27179, aws/aws-cdk#22240

Reason for this change

This PR implements the feature that warns users when non-existent stacks are specified in cdk destroy.

• It does not display the message Are you sure you want to delete: if there is no matching stack.
• Even if the stack does not exist, cdk destroy will not fail, it will just print a warning.

For examples (that have Stacka, StackA, StackX):

Difference from previous PR

The previous PR was reverted in aws/aws-cdk#32839 due to a regression with only nested stage stacks. So this version addresses that regression with comprehensive tests.

Description of changes

The original implementation added warnings for non-existent stacks in cdk destroy, but it failed when applications had only nested stage stacks (no top-level stacks). This happened because the code used allTopLevel: true, which only searched for stacks directly under the App, ignoring stacks within nested Stages.

Fixed the regression by changing suggestStacks method to use DefaultSelection.AllStacks instead of allTopLevel: true, ensuring the warning feature works for all stack configurations (top-level only, nested only, or both). Added regression tests to verify the fix for the nested stage scenario.

  private async suggestStacks(props: {
    selector: StackSelector;
    stacks: StackCollection;
    exclusively?: boolean;
  }) {
    const assembly = await this.assembly();
    const selectorWithoutPatterns: StackSelector = {
-      ...props.selector,
-      allTopLevel: true,
      patterns: [],
    };
    const stacksWithoutPatterns = await assembly.selectStacks(selectorWithoutPatterns, {
      extend: props.exclusively ? ExtendedStackSelection.None : ExtendedStackSelection.Downstream,
-      defaultBehavior: DefaultSelection.OnlySingle,
+      defaultBehavior: DefaultSelection.AllStacks,
    });

Additional Information

When running cdk destroy --all or cdk deploy --all against a configuration with no top-level stacks (nested stages only), the following error occurs.

However, this behavior existed before this PR and is unrelated to the changes made here. Since it is outside the scope of this PR, no fix has been implemented for this behavior.

FYI: I have submitted an issue and a PR about this behavior.

const app = new cdk.App();

new MyStage(app, 'MyStage'); // This has CdkSampleStack

> cdk deploy
Since this app includes more than a single stack, specify which stacks to use (wildcards are supported) or specify `--all`
Stacks: MyStage/CdkSampleStack

> cdk deploy --all
...
No stack found in the main cloud assembly. Use "list" to print manifest

> cdk destroy --all
...
No stack found in the main cloud assembly. Use "list" to print manifest

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.61%. Comparing base (f096a84) to head (532e323).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #984      +/-   ##
==========================================
- Coverage   89.62%   89.61%   -0.02%     
==========================================
  Files          77       77              
  Lines       11752    11752              
  Branches     1650     1650              
==========================================
- Hits        10533    10531       -2     
- Misses       1190     1192       +2     
  Partials       29       29              

Flag	Coverage Δ
suite.unit	89.61% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mrgrain]

@go-to-k I am looking to get this in soon (hence the rebase), but first want to change destroy to use toolkit-lib code internally, so we can avoid duplicate and complicated code.

[go-to-k]

@mrgrain Done. Destroy output now flows through toolkit-lib, so it's coded and consistent with deploy (adds Synthesis time / Destroy time, and the success line is result level). User-facing text is unchanged. (see the diff for the snapshots: packages/aws-cdk/test/commands/_io_snapshots_/destroy/xx.ndjson.)

[go-to-k]

@mrgrain Also restored the confirmation prompt's stack-name color to blue: 4626130

It had turned red because toolkit-lib's destroy used chalk.red, whereas the CLI used chalk.blue before.

Before:

After:

P.S. recommit: d666187

[go-to-k]

Note on the exit code: no-match (W7011) exits 0, while a declined confirmation exits 1 (#1667). This is deliberate and keeps the existing behavior. The old selectStacksForDestroy had a // No validation comment and returned an empty selection, so cdk destroy <nonexistent> already exited 0 (deploy throws NoStacksMatched, destroy never did). We keep that contract and add a warning in place of the old empty prompt.

[go-to-k]

Merged your PR and fixed conflicts.

Now:

[go-to-k]

@mrgrain

Drops this branch's own toolkit-lib migration in favor of upstream #1686, keeps only the destroy warning feature.