feat(filter-in): add applyTo option to limit filtering to specific node types#2536
feat(filter-in): add applyTo option to limit filtering to specific node types#2536balvig wants to merge 1 commit intoRedocly:mainfrom
Conversation
…de types
The `filter-in` decorator uses an `any` visitor which visits all nodes
in the OpenAPI document. When filtering by a property like `tags`, this
can incorrectly match schema property definitions that happen to have
the same name.
For example, a schema with a `tags` property:
```yaml
components:
schemas:
Event:
properties:
tags:
type: array
items:
type: string
```
When using `filter-in` with `property: tags` and `value: App`, the
schema property definition would be filtered out because it has a
`tags` property that doesn't match "App".
This adds an `applyTo` option that allows users to specify which node
type the filter should apply to. For example, `applyTo: PathItem` will
only filter PathItem nodes, avoiding the schema property issue:
```yaml
decorators:
filter-in:
property: tags
value: App
applyTo: PathItem
```
The default behavior (without `applyTo`) remains unchanged for backward
compatibility.
🦋 Changeset detectedLatest commit: a568cdc The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This is a good contribution, @balvig, thank you! However, I'd like to point to a couple of things here. Currently I'm trying to revise the logic at all in scope of this ticket. I'm leaning towards creating a separate decorator (something like What do you think? Wouldn't that new decorator serve your purpose better? |
@tatomyr it probably would! All I really need is a way to filter in/out operations based on tags, without affecting other nodes that happen to have a |
|
@balvig I'll try to file a draft PR later today or early next week. |
|
Thank you @tatomyr, I think so! The particular issue I had was with a child element also containing a |
2 participants
What/Why/How?
When using
filter-inwithproperty: tagsto filter operations by tag, the decorator filters any schema properties that happen to be named "tags", which can case undesirable results in cases such as this:This PR adds an
applyTooption that lets users specify which node type the filter applies to (e.g.,PathItem).This prevents unintended filtering of schema properties while still allowing filtering at the operation level:
Testing
Added a test case that verifies:
Check yourself