Chaining middlewares and options type

[bobgubko]

I have this middleware:

export const projectProviderMiddleware = createMiddleware({
  input: z.object({
    projectId: z.string().transform((value) => parseInt(value, 10)),
  }),
  middleware: async ({ options: { em }, input: { projectId } }) => {
    const project = await em.findOneOrFail(Project, projectId)
    return { project }
  }
})

TS says Property 'em' does not exist on type 'unknown'.ts(2339). It refers to this: { options: { em } }. em is returned by another middleware, but this particular middleware is not aware of that obviously.

How do I set correct type for options in middleware?

[RobinTail]

Hello @bobgubko ,

I can offer you THREE options for doing that.

Option 1: Making it aware

Create an EndpointsFactory equipped with the middleware that provides em.
Then, addMiddleware for creating another factory OR at the moment of creating an Endpoint (using build method).

const customFactory = defaultEndpointsFactory.addMiddleware(
  createMiddleware({
    input: z.object({}),
    middleware: async () => ({ em: { findOneOrFail: () => ({}) } }),
  }),
);

export const anotherFactory = customFactory.addMiddleware(
  createMiddleware({
    input: z.object({
      projectId: z.string().transform((value) => parseInt(value, 10)),
    }),
    middleware: async ({ options: { em } }) => {
      const project = await em.findOneOrFail(); // em is known
      return { project };
    },
  }),
); // here can go .build() if project is only needed for a single endpoint

Option 2: Make is static

I'm not sure what em is, but it looks like a database operation instance.
In case the creation on that entity does not depend on input, you can use addOption similar way.

const customFactory = defaultEndpointsFactory.addOptions({
  em: { findOneOrFail: () => ({}) },
});
// continue same code as from the example above

Moreover, if the chaining approach is not suitable, but em is still static, you can simply export it from another file and import in the file having the projectProviderMiddleware.

import { em } from `src/db_handling`;

export const projectProviderMiddleware = createMiddleware({
  input: z.object({
    projectId: z.string().transform((value) => parseInt(value, 10)),
  }),
  middleware: async ({ input: { projectId } }) => {
    const project = await em.findOneOrFail(Project, projectId)
    return { project }
  }
})

Option 3: Type narrowing

If none of the examples above seem suitable to you, you can check the presence and the type of em option by adding a condition that assures and type of em and narrows it down to the type you expect.

export const projectProviderMiddleware = createMiddleware({
  input: z.object({
    projectId: z.string().transform((value) => parseInt(value, 10)),
  }),
  middleware: async ({ options, input: { projectId } }) => {
    if (
        "em" in options &&
        typeof options.em === "object" &&
        options.em !== null &&
        "findOneOrFail" in options.em &&
        typeof options.em.findOneOrFail === "function"
        // or maybe:   options.em instanceof DatabaseHandler
    ) {
      const project = await options.em.findOneOrFail();
      return { project }
    }
    return { project: null } // endpoint will have to verify that project !== null
  }
})

If em is an instance of some class, it's better to use instanceof condition. That will also automatically infer the return type of the findOneOrFail method.

Moreover, you can simplify all those conditions using Zod schema:

z.object({ 
  em: z.object({
    findOneOrFail: z.function() 
  })
}).safeParse(options)

// or

z.object({ 
  em: z.instance() // in case em is an instance of some class
}).safeParse(options) 

Check out Zod's documentation on safeParse method to utilize it's returns in a condition.

I assume that you're using version 14, which has changed options from Record<string, any> to Record<string, unknown>.
The difference is that you have to make sure that the option exists and has a certain type in exactly this kind of situations, because at the moment of creation Middlewares are not aware in which order you're going to chain them.
Despite a certain difficulty of doing that during the coding, it should protect your application from possible and unexpected runtime errors, @bobgubko .

I hope something of this will help you or at least give you an idea of the further direction.