Version 3

[willfarrell]

Just a collection of ideas for now.

Planned

• Drop Node.js v12 support, add Node.js v16 support
• Better way to handle error responses when using APIG Consider adding a finally phase. #622
  • change run order of onError Order of attaching middleware #707
  • remove return within http-error-handler
  • have Promise.allSettled from getInternal return originalError?
  • change request.error.originalError -> request.error.originalErrors to allow bubble up of error arrays Sqs batch failure error stack #762
• abiltiy to trigger handler cancel before lambda timesouts Global way to force error flow - withTimeout #684
• allow plugin to set internal
• add in stream response support
• Performance & clean up
  • deprecate .applyMiddleware() by meging into .use()?
  • deprecate/change access to .__middlewares
  • deprecate setToEnv in AWS middleware
  • remove header redundancy code - add import httpHeaderNormalizer from '@middy/http-header-normalizer' to examples
  • deprecate s3-key-normalizer and sqs-json-body-parser for event-normalizer, add notice to v2 docs
    • add option to use compiled json parsers
• add plugin hook to flag when internal values change - document with example
• Fix bug where ssm caches Unauthorized requests
• e2e test s3-object-response
• Update TypeScript to match changes
• add tests for streams to http-content-encoding
• add/review tests for http-error-handler
• decide on struct for middy second arg: {...}, {..., plugin:{...}}
• publish as ESM (https://aws.amazon.com/about-aws/whats-new/2022/01/aws-lambda-es-modules-top-level-await-node-js-14/)
• .handler() docs
• timeout docs

[nponeccop]

I don't think dropping 12.x is a good idea. We should keep 12.x for at least as long as it isn't deprecated on AWS, and possibly offer some support for as long as it works at all without resorting to custom runtimes.

As you can see at https://nodejs.org/en/about/releases/ , EOL for 12.x is next year. AWS promises to follow the upstream LTS lifetime, but might offer some support past that.

[willfarrell]

The release of v3 is planned for 2022-04 which lines up perfectly with it's EOL.

[J4YF7O]

I would like to answer because I am very interested in the project.

Node versions support

I agree with @nponeccop , because I think that the role of middy is to be a library usable in the AWS environment (and not only). A library doesn't have to use the latest technology, otherwise it will lose adoption by more people. Moreover, if we look at AWS they stop supporting Node 10 only at the end of the month, and haven't released a runner for Node 16 yet.

I may be wrong, can you elaborate on your thinking @willfarrell ? :)

Typescript

Have you thought about doing the v3 in typescript? It's becoming almost a standard today, and it would probably allow to keep several versions of node in // using "compilation", as it's already done here with babel, and above all it would increase the code quality (IMO).

Would you mind if I tried to create middyts/core for the example?

Minify

...

[willfarrell]

@J4YF7O

In phase 1, Lambda no longer applies security patches or other updates to the runtime.
In phase 2, which starts at least 30 days after the start of phase 1, you can no longer create or update functions that use the runtime.

I don't see value in supporting versions of node that are no longer fit for production use. In the rare, and highly unlikely, case someone must upgrade to the latest version of middy but is required to run it on the oldest version of Node AWS during this small window they will likely already have transpiling in their own build step making this a non-issue.

We plan to release annually to ensure we can take advantage of new features keeping the latest version of middy fast and secure as possible. Ideally the middy publish step doesn't have a transpiling step in it making it easier to debug any issues that arise in production. Middy v3 will not be released until AWS supports Node v16.

Have you thought about doing the v3 in typescript?

Nope, I don't know TypeScript and have no plans to learn. Pivoting to TypeScript would also exclude an entire community from being able to contribute and add additional complexity to the project making it hared to maintain. IMO

Would you mind if I tried to create middyts/core for the example?

Middy has a MIT license, this allow you to do this. However, few others have already done this.

[steelerc69]

@willfarrell Hi, we are currently using v1 of middy and want to upgrade. In the statements above you mention that aws sdk v3 is not likely to be supported. Is that statement still true? Are you planning an upgrade to aws sdk v3 outside of middy v3 if so?
Thanks for the awesome work.

[willfarrell]

@steelerc69 Currently [email protected] is not included as part of the default lambda runtime (https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html). This means that using [email protected] will result in a smaller bundle size, leading to faster cold starts (though a very small amount). See #584 for all outstanding issues with [email protected]. Middy v3 will most likely continue to use [email protected]. Once the AWS Lambda team considers [email protected] to be production ready, we will for sure upgrade for the next major release.

That said, the code for using [email protected] has been written, but commented out, if you really need it.

[jimmywarting]

TypeScript + ESM is a nightmare atm... it's just a another unnecessary language that don't work anywhere and must be compiled to javascript to run. it's very much possible to have type safety and avoid all the need of compiling using jsdoc

[willfarrell]

alpha is now released