feat: support variadic middleware for routes

[swain]

Motivation

Many existing LifeOmic services use the "variadic middleware" style when declaring routes:

router.get(
  '/something',
  middleware1,
  middleware2,
  middleware3,
  actualImplementation
);

Currently, it's very diffuclt to adopt one-schema in a service that uses this^ pattern, since it can't be represented in a OneSchemaRouter without significant refactoring.

That changes today! This PR introduces support for this syntax in a non-breaking way, thanks to TypeScript magic:

router
  // This is the preferred path, supported today. Single implementation function. This is preferred + clearer!
  .implement(
    'POST /items',
    async (ctx) => {
      return item;
    }
  )

  // But now, this also works:
  .implement(
    'POST /items',
    async (ctx, next) => {
      await doSomethingElse();
      await next();
    },
    async (ctx) => {
      return item;
    }
  )

  // You can have many middlewares.
  .implement(
    'POST /items',
    middleware1,
    middleware2,
    middleware3,
    // The last function in the list _must_ return the required response.
    async (ctx) => {
      return item;
    }
  )

With this^ change, it will be much easier to adopt one-schema in existing services.

[epeters3]

Wow, TIL you can spread a type.

[epeters3]

Actually, this is a rest, not a spread.

[epeters3]

Very cool.

[epeters3]

So this above type for middlewares will require 0 to many OneSchemaRouterMiddleware parameters, followed by exactly 1 required EndpointImplementation parameter?

[swain]

@epeters3 Exactly! Previously, I thought this was impossible to model using TS. I was wrong :)

[epeters3]

Way cool. I think the fact that Typescript is fundamentally a correctness checker and DX tool and not just a necessary part of code compilation like with Java or C, has enabled the Typescript maintainers and community to do some pretty incredible things.

[aecorredor]

What is actually making the jest assertions here? Or are we just relying on the @ts-expect-error directives to act like a unit test?

[swain]

Yep, just the ts-expect-error directives. This pattern is used in many tests in this project.

[aecorredor]

What was the reason for having to cast as any here?

[swain]

middlewares doesn't narrow enough -- it's typed as roughly Array<Middleware | Implementation>

[github-actions]

🎉 This PR is included in version 5.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀