Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening for extension #189

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Opening for extension #189

wants to merge 6 commits into from

Conversation

bartoszm
Copy link
Contributor

@bartoszm bartoszm commented Sep 27, 2023

Two extension points added:

  • to provision own validator instance
  • to provision spec postprocessor

Fixes #188

@codekie
Copy link
Owner

codekie commented Sep 28, 2023

Be aware that the API is not officially supported. This tool is a CLI-tool in the first place. When changes are made and the API is affected by them, it will not be reflected in the semantic versioning. If you intend to use the API it is on your own risk.

However, I don't mind having this as an extension, but you will have to add automated tests and best with one or more meaningful use-cases, before it will be merged. Also, consequently the new properties should be available on all validate-functions then.

@bartoszm
Copy link
Contributor Author

bartoszm commented Oct 4, 2023

I have enabled the API extension for all methods of public API. Added some simple tests.
For validatorFactory it is a clone of index.js test with a custom Ajv instance
For schema modification, I show how you can use postprocessor to force readOnly validation as OAS defines it (basic variant from #114)

@bartoszm
Copy link
Contributor Author

Hi @codekie. I have rebased it on top of my previous contribution. Please let me know what you think.

Copy link
Owner

@codekie codekie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general. Maybe consider to support the consumption of an array of post-processors (instead of just one) where the result of the predecessor passes the result as input to the next post-processor so that they can be chained. Would that make sense? What do you think?

src/index.js Outdated Show resolved Hide resolved
test/specs/extensions.js Outdated Show resolved Hide resolved
test/specs/extensions.js Show resolved Hide resolved

// TEST SUITES

describe('Main API', function() {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these test-cases test if it successfully uses the custom factory? Won't the validation-results here be the same if omit the custom factory?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes it would. My point in this test was to show that the injection mechanism works as expected. In other words that injecting Ajv from outside with no modification you should expect the same results as if you would use the build in one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want I can add a test showing using different Ajv instance. Frankly thats my primary use case. I want to detect additional properties even if you use composed schemas. So for that I can use unevaluatedProperties that is supported by Ajv 2019. So it work in combo. In postprocessor I am adding unevaluateProperties flag and I am using Ajv 2019.

Another use case would be to configure Ajv instance with custom validations (https://ajv.js.org/guide/user-keywords.html)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have at least one test case that tests a different configuration. Just to have that covered as well.

@bartoszm
Copy link
Contributor Author

LGTM in general. Maybe consider to support the consumption of an array of post-processors (instead of just one) where the result of the predecessor passes the result as input to the next post-processor so that they can be chained. Would that make sense? What do you think?

Hi, it does make sense. But can be easily achieved by chaining functions externally. I have modified the test code to illustrate that. Maybe lets keep it as is for now?

@bartoszm
Copy link
Contributor Author

bartoszm commented Dec 3, 2023

@codekie could you let me know what do you think about this MR ? what is missing / unclear ?

@codekie
Copy link
Owner

codekie commented Dec 4, 2023

@bartoszm sorry for the slow responses, but I've been very busy with ongoing projects the past weeks. I hope that I'll have time to have a closer look at this, this week. I'll address you if I have questions.

@bartoszm
Copy link
Contributor Author

bartoszm commented Dec 5, 2023

@bartoszm sorry for the slow responses, but I've been very busy with ongoing projects the past weeks. I hope that I'll have time to have a closer look at this, this week. I'll address you if I have questions.

No worries, I've been there many times :)

Copy link
Owner

@codekie codekie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Only additional tests cases for the custom factory would be good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow for extensions
2 participants