assertions: Allow to use wildcard when specifying constructPath of Annotations

[tmokmss]

Describe the feature

Currently we can use methods like Annotations.hasError for either 1. all the constructs or 2. one specific construct.

// 1. Find errors in every construct
Annotations.fromStack(stack).findError('*', 'foo');

// 2. Find errors in the specific path
Annotations.fromStack(stack).findError('/Stack/Some/Resource', 'foo');

Now it will be much more useful if we can specify more granular match like prefix match.

// Find errors under the specific path
Annotations.fromStack(stack).findError('/Stack/Some/Resource/*', 'foo');

Use Case

I'd like to do more granular test on a specific construct. It would be ideal if we can use something like glob pattern to specify the construct path.

For example, when using with cdk-nag, we can check the vulnerabilities only for a specific construct and its children.

Proposed Solution

Use minimatch library here instead of v.id === path. minimatch is already used in aws-cdk-lib so it should not affect bundle size.

aws-cdk/packages/aws-cdk-lib/assertions/lib/private/messages.ts

Lines 56 to 58 in d99733f

	return Object.entries(section ?? {})
	.filter(([_, v]) => v.id === path)
	.reduce((agg, [k, v]) => { return { ...agg, [k]: v }; }, {});

However, because we can use special characters such as * or + in a construct id, the syntax of minimatch conflicts with them. We have to consider a workaround to introduce this feature without breaking changes.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.81.0

Environment details (OS name and version, etc.)

macOS

[peterwoodworth]

Very reasonable request, we welcome contributions!

[tmokmss]

Thanks @peterwoodworth. Actually it turned out not to be that simple as I thought at first.

Because we can use special characters such as * or + in a construct id, the syntax of minimatch conflicts with them. Because of this, if we naively allow to use * as wildcards in constructPath arg, it can be a breaking change.

We have to consider a workaround to introduce this feature without breaking changes.

[peterwoodworth]

Because we can use special characters such as * or + in a construct id

huh, TIL. Good catch on this