improv(tests): adopt aws cdk cli lib

[dreamorosi]

Description of your changes

Note
This PR supersedes #1624 and proposes a much reduced scope compared to that PR.

This PR introduces a new testing utility that at the moment contains only a new class called TestStack. This class is a simple wrapper around the @aws-cdk/cli-lib-alpha module and provides only the minimum amount of methods needed to synth, deploy, and destroy a CDK Stack.

This driver behind this change, as detailed in the linked issue, stems from the reliance of our current integration/e2e tests on an internal CDK command line which has changed in a recent release and thus has locked us out of newer and patched versions of CDK.

Since our first implementation of the integration tests over a year ago, CDK has released a new package (@aws-cdk/cli-lib-alpha) that allows to interact with the CLI programmatically, and that can replace our current implementation. Even though the package is in alpha, we consider this still to be an improvement over reliance on internal API, and we hope that through our usage we can help shape the package.

As mentioned above, this is the second PR that tries to apply this change. The previous PR was much larger in scope and in addition to introducing the new CLI wrapper, it also added a ton of new utilities. After discussing internally we have however decided to leave these changes out and work on a RFC before attempting to implement them.

The changes in this PR constitute a stop-gap solution that allows us to move away from the internal CDK API and access current versions of CDK. Once the RFC mentioned will be out and discussed, I am open to decommission the changes introduced this PR in favor of a more solid implementation.

While working on the PR I prioritized keeping changes in the codebase as low as possible, even though there are several areas (i.e. standard resource factories) that could have resulted in a more streamlined implementation.

Detailed list of changes:

• Removed of all aws-cdk-related (i.e. http-proxy, vm2, etc.) dependencies from the project
• Removed cdk-cli util from commons [1]
• Created a new internal testing utility
• Added aws-cdk-lib as dependency scoped to the testing module
• Added aws-cdk & aws-cdk-lib as scoped dependencies to the layers package [2]
• Minimal changes to tracer e2e tests to use the new package + added the new package as devDependency
• Minimal changes to logger e2e tests to use the new package + added the new package as devDependency
• Minimal changes to metrics e2e tests to use the new package + added the new package as devDependency
• Minimal changes to idempotency e2e tests to use the new package + added the new package as devDependency
• Minimal changes to parameters e2e tests to use the new package + added the new package as devDependency
• Changes to layers e2e tests to use the new package + added the new package as devDependency [3]

Notes:
[1] This was an internal module that was never published to npm, so I don't think it constitutes a breaking change
[2] Since the CLI is used as an actual CLI in the CI for this package, we don't need the additional dependencies and we are not relying on any internal
[3] The diff here is slightly higher compared to the other packages because this e2e test deploys two CDK apps/stacks

Related issues, RFCs

Issue number: #1623

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[dreamorosi]

Integration test, using the new module, ran successfully: https://github.com/aws-powertools/powertools-lambda-typescript/actions/runs/5682665966

[dreamorosi]

Also, SonarCloud is going to most probably bring up a ton of findings because the PR touches many existing files that have a lot of code.

I will happily address any finding on the newly added code (packages/testing/*), but in order to keep the diff contained & in light of what discussed in the PR body as well as the fact that these are internal test files, I would suggest to not dedicate time to rework other findings.

[am29d]

Thanks for the PR! The new cli interface looks clean and we finally have a dedicated place for the testing lib.

I have left only one small comment.

[am29d]

I will happily address any finding on the newly added code (packages/testing/*), but in order to keep the diff contained & in light of what discussed in the PR body as well as the fact that these are internal test files, I would suggest to not dedicate time to rework other findings.

I agree, let's address the changes in a dedicated PR.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
4.5% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[am29d]

🚀