Allow filtering of paths

[TheHaff]

Status

READY

Description

I had a local script that pruned my openapi file and thought maybe you would like the same functionality.
The signature is [pathUrl, [get, delete]].

Related PRs

List related PRs against other branches:

branch	PR
other_pr_production	link
other_pr_master	link

Todos

• Tests
• Documentation
• Changelog Entry (unreleased)

Steps to Test or Reproduce

Outline the steps to test or reproduce the PR here.

> git pull --prune
> git checkout <branch>
> grunt jasmine

[soartec-lab]

@TheHaff
Thanks for the suggestion. Let me check before looking at the source code.

Wouldn't it be enough to narrow down the target endpoints by changing the tags?
In the case of tags, you can specify them on an endpoint-by-endpoint basis, and filters already exist.

[TheHaff]

This is more for the case of frontend people working towards a monolithic big boi backend. I wouldn't dare go in there and change stuff and this allows me to avoid unused endpoints. I will also be adding some more checks like if path not found or method not found to make it a bit more robust.

[Armanio]

@TheHaff
Very impressive work!

But I have to ask: input.override.transformer isn't it suitable for the task of path filtering?

[TheHaff]

@TheHaff Very impressive work!

But I have to ask: input.override.transformer isn't it suitable for the task of path filtering?

You could use input.override.transformer to filter paths, but the dedicated filters.paths feature adds functionality a transformer alone doesn't provide.

Differences

1. Schema dependency analysis (primary)

   • Path filters automatically analyze which schemas are referenced by filtered operations and include those dependencies
   • With a transformer, you'd need to manually trace references (request bodies, responses, parameters) and include related schemas
   • The filter system handles this via filterSchemasByDependencies

2. Integrated filtering

   • Path filters work with tags, schemas, and mode (include/exclude) as a unified system
   • A transformer would duplicate this logic if you want to combine filters

3. Method-specific filtering

   • Supports [path, [methods]] for per-path method filtering
   • More ergonomic than manually filtering PathItemObject methods in a transformer

4. Execution timing

   • The transformer runs early (transforming the spec)
   • Filters run later in the generation pipeline, after the spec is normalized
   • This separation lets transformers focus on spec transformation, while filters handle generation-time filtering

5. Declarative vs imperative

   • Filters: filters: { paths: ['/pets', /health/] }
   • Transformer: requires writing a function that manipulates the OpenAPIObject

[melloware]

@TheHaff up to you. Either would be great.

[TheHaff]

I have this as a patched version in my project for now, If this makes sense for the project it would be great to get this in. Maybe my case is too niche? You can imagine having a bunch of micro service backend calls mixed in with the exposed frontend calls. I don't have direct say or capacity at backend to organize tags.