The original intention here is to do:

Template.fromStack(stack).hasResourceProperties('AWS::ElasticLoadBalancingV2::TargetGroup', Match.not({
  ...
});

@rix0rrr seems to hate this but I think it's reasonable; Match.not simply inverts the result so it succeeds with any matching failure. Curious if this is something you looked at and actively avoided.

I looked at it, it just felt... wrong? And it's not entirely equivalent; for example, the above fails if there are no TargetGroups. Maybe I should be using it, as I guess it's the more idiomatic approach for assertions, but something about the way the API currently expresses itself makes me wrinkle my nose a bit. I'd like to think of a better approach, but also didn't want to block this migration on it.

Thanks for the response. The equivalence issue is true, but to play devils advocate, I don't think the Assertions API was developed with the idea of exact 1-1 matching with assert-internal. But I hear what both you and Rico are saying.

@kaizen3031593 this looks like the solution to what we were talking about yesterday.

Good call. Although I am about to write a PR for messages support that would look something like this:

AssertAnnotations.fromStack(stack).hasWarning('*', {
  entry: {
    type: 'aws:cdk:warning',
    data: "fromVpcAttributes...",
  },
});