feat: self-composing UseFN

[vicary]

In respond to #769 (comment), this is the first attempt to make the event object self- and auto- composing through the chain of .use().

Intended usage:

import type middy from "@middy/core";
import type { Context } from "aws-lambda";

const middyFoo = (): middy.MiddlewareObj<{ evtFoo: string }, any, Error, Context & { ctxFoo: string }> => ({
  before: ({ context, event }) => {
    context.ctxFoo = "foo";
    event.evtFoo = "foo";
  },
});

const middyBar = (): middy.MiddlewareObj<{ evtBar: string }, any, Error, Context & { ctxBar: string }> => ({
  before: ({ context, event }) => {
    context.ctxBar = "bar";
    event.evtBar = "bar";
  },
});


export const handler = middy()
  .use(middyFoo())
  .use(middyBar())
  .before(({ context: { ctxFoo, ctxBar }, event: { evtFoo, evtBar } }) => {
    // context and event inherits new properties from the .use() above
  })
  .handler(({ evtFoo, evtBar }, { ctxFoo, ctxBar }) => {
    // context and event inherits new properties from the .use() above
  });

[vicary]

@willfarrell Should it be 3.0 or 4.0?

Also some old plugins add something to lambda context, while others add to events. I am kinda leaning towards extending the event object, so I intentionally left TContext untouched. Do you have a preference or encourage either side?

[willfarrell]

v4 is on hold till we know what AWS is going to do for their next runtime update (v18). That could be as early as Sept, or a year from now. I'm open to minor changes for v3 for now. There can also be a separate PR for v4, to allow others to comment.

Changes to the event are the most common use in middlewares, however non-external inputs (ie secrets, db connections, etc) should live in the context.

I personally don't use TS, so it's up to the community to decide what is best for Middy. This PR looks safe fro v3.

[vicary]

My team is currently adding everything to event, including typeorm and fetch, to make handlers testable.

But I want this PR to be generally aligned with your advertised usage, I'll update it again to have TContext also inherits through the chain of .use().

[vicary]

@willfarrell It's ready now.

Tried avoiding the necessity of Context & ... in usage, but that breaks the extends LambdaContext check. I chose to retain a more guaranteed typing.

Usage example in the description is updated to reflect the change.

[vicary]

We may update the types in all packages, shall I do that here or in a new PR?

For example, @middy/cloudwatch-metrics with typings:

export const handler = middy()
  .use(cloudwatchMetrics())
  .handler(({}, { metrics }) => {
    // The `metrics` property and its methods will be discoverable by IDEs
  });

[willfarrell]

Within this PR is fine.

[vicary]

@willfarrell added types for middlewares, please comment.

[vicary]

TypeScript has no way to perform string matching without introducing unused vars, I have to skip these errors.

middy/packages/ssm/index.d.ts

Lines 10 to 11 in bd4badd

	// eslint-disable-next-line @typescript-eslint/no-unused-vars
	type ExtractSingles<T> = T extends `/${infer _}` ? never : T

middy/packages/ssm/index.d.ts

Lines 18 to 19 in bd4badd

	// eslint-disable-next-line @typescript-eslint/no-unused-vars
	(keyof TOptions['fetchData'] extends `${infer _P}/${infer _S}`

[vicary]

Took another look at SSM and noticed a mistype, fixed it.

Sidenote: ts-standard is broken

ts-standard (npm run test:lint:ci) is not suitable for typescript linting because there are broken rules, for example typescript-eslint/typescript-eslint#1824.

I think we should use eslint directly so we can opt-in and out of particular rules, along with eslint-plugin-prettier so contributors can easily fix trivial format misalignments.

That's for another PR though, I'll stick with the broken indentations here to stay green.

[vicary]

Rebased

[willfarrell]

Looks good to me. I'm going to leave it open in case other would like to comment. I can merge and release next week. Thanks for all of the hard work putting this together.