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

feat(packages): add option to filter generated endpoints #810

Merged
merged 1 commit into from
Apr 8, 2023

Conversation

yesyesufcurs
Copy link
Contributor

In the case orval is run on a system with a lot of endpoints, it can be useful to limit which endpoints are actually generated.

Status

READY

Description

In the case orval is run on a system with a lot of endpoints,
it can be useful to limit which endpoints are actually generated.

See: #739

Todos

  • Tests
  • Documentation
  • Changelog Entry (unreleased)

Steps to Test or Reproduce

Outline the steps to test or reproduce the PR here.

  1. Add a tag that should be filtered out to a orval.config for instance as follows:
output: {
      filterTags: ["pets"]
},
  1. Only end points that contain tag "pets" will be generated.

@vercel
Copy link

vercel bot commented Mar 22, 2023

Someone is attempting to deploy a commit to a Personal Account owned by @anymaniax on Vercel.

@anymaniax first needs to authorize it.

jordanrigo
jordanrigo previously approved these changes Apr 1, 2023
@@ -51,6 +51,7 @@ export type NormalizedOutputOptions = {
tsconfig?: Tsconfig;
packageJson?: PackageJson;
headers: boolean;
filterTag?: string[];
Copy link
Collaborator

Choose a reason for hiding this comment

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

What do you think about having this.

filters?: {
  tags?: string[]
}

Like that we can add other filters like on the operation id.

What do you think about adding it in the input section and not the output 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.

I agree with changing it to have a filters object, that would make more sense. I will be updating this asap.

About the input section I'm not sure. I think it is more of a question how we see it:

  1. We only "read in" the relevant filtered elements.
  2. We only "output" the relevant filtered elements.

The first one would imply adding it in the input section, the second one the output section.
The main reason I chose to add it to the output section is since the function that I changed in the api.ts file only receives NormalizedOutputOptions as parameter. I could of course add the NormalizedInputOptions as parameter to get the desired change, or do you think there would be a smarter way to go about this?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I would do the filter here and so we don't even read the operation. And in that case, you can also pass the NormalizedInputOptions as a parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have fixed it as you proposed :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Really nice works! Thanks for the pull request

In the case orval is run on a system with a lot of endpoints,
it can be useful to limit which endpoints are actually generated.
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.

3 participants