4.3.x Custom resolvers are incompatible with options.apiSpec set to path.

[aviskase]

Related to #416

Describe the bug
After upgrading to 4.3.x custom resolvers are incompatible with options.apiSpec set to path.

In 4.2.3 custom resolver was working with:

resolver: (basePath: string, route) => {
 const functionName = route.schema['operationId'];
 ...

In 4.3.x custom resolver had to be change to different approach because there is no longer .schema property in the route:

resolver: (basePath: string, route, apiDoc) => {
  const pathKey = route.openApiRoute.substring(route.basePath.length);
  const schema = apiDoc.paths[pathKey][route.method.toLowerCase()];
  const functionName = schema['operationId'];
  ...

But it relies on installOperationHandlers to send apiDoc always as an object, whereas per line

express-openapi-validator/src/openapi.validator.ts

Line 321 in ed7af2b

router[method.toLowerCase()](path, resolver(basePath, route, this.options.apiSpec));

it sends whatever was defined in options (in my case, path to API description doc).

[aviskase]

I found that apiDoc argument was introduced in #366 in version 3.17.x , so I think the are two problems here:

• for some reason, route.schema is now undefined
• apiDoc is better to be loaded into object before passing into resolver (for uniformity)

[cdimascio]

thanks @aviskase
router[method.toLowerCase()](path, resolver(basePath, route, this.options.apiSpec)); should be
router[method.toLowerCase()](path, resolver(basePath, route, context.apiDoc));
feel free to create a PR with the change, and i'll get it merged. if not, i'll get it done tonight

[aviskase]

yup, will do

[cdimascio]

i'll revisit schema. i removed it as part of the readOnly/required work. not something i wanted to do, but felt was necessary to ensure solid performance.
background:
in order to handle the schema for readOnly vs writeOnly using ajv, i need to manipulate the schema's required property based on the case (readOnly vs writeOnly). the validator manipulates the required prop once on schema load (as opposed to per api request) for efficiency. though efficient, it has a downside, in that two very similar variants of the apiDoc exist. i want to explore other mechanisms before exposing this (not so ideal) implementation detail to the user through an API.

[cdimascio]

fixed in v4.3.5. thanks @aviskase !