search

kogosoftwarellc / open-api

A Monorepo of various packages to power OpenAPI in node
MIT License
892 stars 235 forks source link

openapi-request-validator: add ajv options #737

Closed nicofuccella closed 2 years ago

nicofuccella commented 3 years ago

This PR allow pass extra options to Ajv validator for example to enable removeAdditional.

Inspired by: https://github.com/kogosoftwarellc/open-api/pull/709

giowe commented 3 years ago

need this!

jsdevel commented 3 years ago

please update this PR with the latest in master. ajv was recently updated.

nicofuccella commented 3 years ago

@jsdevel done

nicofuccella commented 3 years ago

@jsdevel can we merge this?

nicofuccella commented 3 years ago

@jsdevel can we merge this?

jsdevel commented 3 years ago

@nicofuccella sorry for the delay here. @asarver and i ran into issues getting the ajv bump published, but it should be good now with the latest. can you update again please? i'll merge as soon as you do so and the build is passing. thanks!

jsdevel commented 3 years ago

@nicofuccella can you update this ? had to migrate to github actions.

jsau- commented 2 years ago

@jsdevel @nicofuccella Just as a heads up, I'll be putting in a pull request either later today or tomorrow that has some overlap with the intention of this PR.

My pull request will be about allowing library consumers to provide their own classes for request and response validation (and all other features - coercers, default setters, security handlers).

eg. Adding the following to type OpenAPIFrameworkArgs

  features?: {
    coercer?: new (args: OpenAPIRequestCoercerArgs) => IOpenAPIRequestCoercer;
    defaultSetter?: new (
      args: OpenAPIDefaultSetterArgs
    ) => IOpenAPIDefaultSetter;
    requestValidator?: new (
      args: OpenAPIRequestValidatorArgs
    ) => IOpenAPIRequestValidator;
    responseValidator?: new (
      args: OpenAPIResponseValidatorArgs
    ) => IOpenAPIResponseValidator;
    securityHandler?: new (
      args: OpenAPISecurityHandlerArgs
    ) => IOpenAPISecurityHandler;
  };

I think this approach might be more useful in the general case. Consumers of the library are free to write their own classes customizing the behavior of the library's default packages in whatever way they please, and it can lead to some performance improvements in test suites for large APIs which I'll go into detail on in the PR I raise.

EDIT: https://github.com/kogosoftwarellc/open-api/pull/785 raised.

jsdevel commented 2 years ago

i'm gonna close this soon unless there is some activity