feat(internal): support Middy.js 5.x

[dreamorosi]

Summary

Changes

Please provide a summary of what's being changed

This PR adds support for Middy.js 5.x by including it in some of the integration test cases that are run on the utilities and widening the version range in the peer dependencies from >= 4.x to 4.x || 5.x.

Because we want to continue supporting both versions, I decided to use an npm feature that allows you to install a package under a custom alias. This mechanism allows multiple versions of the same-name package side-by-side, which is what we need in this case.

To modify the devDependencies of the project I run these commands:

npm un @middy/core # remove existing version
npm i -D middy4@npm:@middy/[email protected]
npm i -D middy5@npm:@middy/[email protected]

This created two entries in the main package.json file, and allows us to import either of the two versions using the name of the alias like so:

import middy from 'middy5'; // this will resolve to the node_moduels/middy5/* contents

With this, I switched some of the test cases that were already running using ESM output to import v5, and left the others untouched.

I also updated the docs to reflect that we support both versions.

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: #2049

---

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.

[am29d]

Great addition of middy5! Few questions:

With this, I switched some of the test cases that were already running using ESM output to import v5, and left the others untouched.

Does this imply that not all e2e tests that can run with middy5 are covered and we need to add them overtime? Will this result in duplication?

I just realised that we need to fix our peerDeps for parser as well :| will do in a separate PR.

[dreamorosi]

Does this imply that not all e2e tests that can run with middy5 are covered and we need to add them overtime?

Currently we have a number of e2e test cases (i.e. 10 <- fictional number for the sake of the argument). Of these 10, today we are running some of them (i.e. 5) using ESM and some other (i.e. the other 5) with CJS.

Generally speaking, the distribution between the two has been done in a way that each utility has at least 1 or more tests running in each mode.

Because of Middy.js 5.x only supporting ESM, the pool of eligible test cases where to import middy5 is reduced to these cases only. On the other hand, generally speaking each utility only has one test group (i.e. this is one) that runs tests on functions using Middy.

With all this in mind, the changes in the PR ensure that at least one group of tests for each utility is testing Middy.js 5. I didn't add any new test, and I don't think we should do so, because we are already testing different combinations when looking at the tests all together.

[dreamorosi]

I just realised that we need to fix our peerDeps for parser as well :| will do in a separate PR.

Added in the last commit - good catch!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[am29d]

Great work as always, I am sure the middy5 support release will be a surprise for many 😎