A minimal, self-contained example of the root-config filter option, which
restricts code generation to a subset of the input document's paths/operations
instead of everything.
openapi.json defines four operations:
| Path | Operation | Response schema |
|---|---|---|
GET /users |
listUsers |
User (→ Address) |
GET /users/{id}/audit |
getUserAudit |
AuditEntry |
GET /orders |
listOrders |
Order |
GET /metrics |
getMetrics |
Metrics |
filter: {
include: ['/users', '/users/**', '/orders'],
exclude: ['/users/{id}/audit']
}Patterns are minimatch globs, matched
against the path template or the operationId. exclude is applied after
include, so an excluded item is always dropped. An empty/absent filter
generates everything, unchanged.
Note:
/users/**matches nested paths like/users/{id}/auditbut not/usersitself — list both when you want the collection and everything under it.
Running the generator:
npm run generateproduces payload models for only the retained operations:
src/generated/payloads/
├── User.ts # kept: /users
├── Address.ts # kept: referenced by User (nested)
├── ListUsersResponse_200.ts # kept: /users response
├── Order.ts # kept: /orders
└── ListOrdersResponse_200.ts # kept: /orders response
Filtered out:
/users/{id}/audit— matchedincludevia/users/**but removed byexclude, so nogetUserAuditmodels are generated./metrics— never matchedinclude, so it is dropped.AuditEntryandMetrics— component schemas referenced only by the dropped operations, so they are pruned automatically (orphan pruning).Addresssurvives because it is still referenced by the retainedUser.
- Filtering happens once, while the document is loaded, so every generator (payloads, parameters, headers, types, channels, client) sees the already subsetted document — no per-generator configuration needed.
- The same
filteroption works for AsyncAPI input, where patterns match against channel address, channel id, or operation id. - JSON Schema input has no
filter(it has no paths/channels to filter).