{"id":28333848,"url":"https://github.com/itwillwork/openapi-modifier","last_synced_at":"2026-03-02T17:04:31.217Z","repository":{"id":294011717,"uuid":"737249453","full_name":"itwillwork/openapi-modifier","owner":"itwillwork","description":"This package allows you to automate the process of modifying OpenAPI specifications by applying a set of predefined rules","archived":false,"fork":false,"pushed_at":"2026-01-28T12:07:53.000Z","size":1225,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-01-29T01:10:55.146Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/itwillwork.png","metadata":{"files":{"readme":"README-ru.md","changelog":null,"contributing":"docs/contributing-ru.md","funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-12-30T10:45:38.000Z","updated_at":"2026-01-28T12:07:56.000Z","dependencies_parsed_at":"2025-05-18T17:33:26.092Z","dependency_job_id":null,"html_url":"https://github.com/itwillwork/openapi-modifier","commit_stats":null,"previous_names":["itwillwork/openapi-modifier"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/itwillwork/openapi-modifier","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itwillwork%2Fopenapi-modifier","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itwillwork%2Fopenapi-modifier/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itwillwork%2Fopenapi-modifier/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itwillwork%2Fopenapi-modifier/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/itwillwork","download_url":"https://codeload.github.com/itwillwork/openapi-modifier/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/itwillwork%2Fopenapi-modifier/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30011189,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-02T17:00:27.440Z","status":"ssl_error","status_checked_at":"2026-03-02T17:00:03.402Z","response_time":60,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-05-26T20:55:04.021Z","updated_at":"2026-03-02T17:04:31.204Z","avatar_url":"https://github.com/itwillwork.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"[🇺🇸 English](./README.md) | [🇷🇺 Русский](./README-ru.md)  | [🇨🇳 中文](./README-zh.md)\n\n# OpenAPI Modifier\n\nИнструмент для модификации OpenAPI спецификаций с помощью настраиваемых правил. \n\nЭтот пакет позволяет автоматизировать процесс изменения OpenAPI спецификаций, применяя к ним набор предопределенных правил.\n\n## Основные возможности\n\n- Модификация OpenAPI спецификаций в форматах YAML и JSON\n- Гибкая система правил для изменения спецификаций\n- Поддержка как CLI, так и программного использования c поддержкой TypeScript\n\n\u003e [!IMPORTANT]  \n\u003e Поддерживает OpenAPI 3.1, 3.0. Мы не проверяли поддержку OpenAPI 2, так как формат является устаревшим и рекомендуем мигрировать вашу документацию на OpenAPI 3.0.\n\n## Мотивация и примеры использования\n\nOpenAPI описывающий бекендное API далеко не всегда идеальное: содержит ошибки, неточности или какие-то особенности ломают другие инструменты, например, кодогенерацию или генерацию типов.\n\nХранить информацию об изменения в декларативном формате, чтобы был понятент контекст и актуальность каждого изменения, особенно полезно в крупных коммандах.\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003cb\u003eДругие случаи применения\u003c/b\u003e\u003c/summary\u003e\n\n### Другие случаи применения:\n\n- Бекендер просит проверить используется ли поле в какой-то сущности;\n- Бекендер просит проверить используется ли параметр в какой-то ручке; \n- Бекендер создает задачу перестать пользоваться endpoint'ом;\n- Бекендер написал новое API в разработке, но его нет в документации;\n- Бекендер просит больше не использовать какой-то параметр в endpoint'е;\n- Не валидное OpenAPI (например, использовали не существующий тип int);\n- Нужно оставить знания по модификации (коллеге важно знать почему какое-то поле заблокировано);\n- Нужно наблюдать за изменениями API и вовремя корректировать конфиг (убрали использование ручки);\n- Убирать deprecated поля из openapi (чтобы вовремя замечать возможности api которые будут удалены);\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003cb\u003eДемонстрация использования\u003c/b\u003e\u003c/summary\u003e\n\n\u003ca name=\"custom_anchor_demo\"\u003e\u003c/a\u003e\n\n### Демонстрация использования\n\nНапример имеем [входной файл спецификации/документации api](./examples/example-cli-generate-api-types/input/openapi.yaml) от бекенд разработчиков. Например, [скачен через curl cli из github](./examples/example-cli-generate-api-types/package.json#L11).\n\nПишем [файл конфигурации](./examples/example-cli-generate-api-types/openapi-modifier.config.ts), описывающий все что нужно поменять в исходной спецификации/документации с пояснительными комментариями:\n\n```ts\nconst config: ConfigT = {\n    pipeline: [\n        // JIRA-10207 - new feature API for epic JIRA-232\n        {\n            rule: 'merge-openapi-spec',\n            config: {\n                path: 'input/feature-openapi-JIRA-232.yaml',\n            },\n        },\n\n        // ...\n\n        // JIRA-10212 - wrong docs, waiting JIRABACKEND-8752\n        {\n            rule: 'patch-schemas',\n            config: [\n                {\n                    descriptor: {\n                        type: 'component-schema',\n                        componentName: 'Pet',\n                    },\n                    patchMethod: 'merge',\n                    schemaDiff: {\n                        properties: {\n                            id: {\n                                type: 'string',\n                                format: 'uuid',\n                            },\n                        },\n                    },\n                },\n            ],\n        },\n\n        // ...\n\n        // JIRA-11236 - removed deprecated endpoint, waiting JIRABACKEND-3641\n        {\n            rule: 'filter-endpoints',\n            config: {\n                disabled: [\n                    {\n                        path: '/v1/pets/{petId}',\n                        method: 'delete',\n                    },\n                ],\n            },\n        },\n\n        // ...\n}\n```\n\nДалее [при помощи этого файла конфигурации и cli openapi-modifier](./examples/example-cli-generate-api-types/package.json#L7), изменяем исходный файл спецификации/документации и получается [модифицированная спецификация/документация](./examples/example-cli-generate-api-types/output/openapi.yaml).\n\nДалее при помощи, к примеру cli [dtsgenerator](https://github.com/horiuchi/dtsgenerator), генерируем из модифицированной спецификации/документаци [файл типизации для api](./examples/example-cli-generate-api-types/output/generated-api-types.d.ts), которую уже используем в коде проекта.\n\n[Полный код примера](./examples/example-cli-generate-api-types)\n\n\u003c/details\u003e\n\n## Установка\n\n```bash\nnpm install --save-dev openapi-modifier\n```\n\n## Использование\n\n\u003ca name=\"custom_anchor_cli_npx_usage\"\u003e\u003c/a\u003e\n\n### CLI через NPX\n\n```shell\nnpx openapi-modifier --input=input/openapi.yml --output=output/openapi.yml --config=openapi-modifier.config.js\n```\n\n[Пример использования как CLI через NPX](./examples/example-cli-simple-npx/package.json#L6)\n\nCLI параметры:\n\n| Опция    | Описание                                                                                                 | Пример                       | Дефолтное                                    |\n| -------- | -------------------------------------------------------------------------------------------------------- | ---------------------------- |----------------------------------------------|\n| `input`  | [**обязательный**] входной файл, специфиакция/документация в формате openapi                             | `input/openapi.yml`          |                                              |\n| `output` | [**обязательный**] выходной файл, специфиакция/документация в формате opeanpi                            | `output/openapi.yml`         |                                              |\n| `config` | путь до файла конфигурации. Детальное описание конфигурации [см. ниже](#custom_anchor_config_parameters) | `openapi-modifier.config.js` | `openapi-modifier.config.(js\\ts\\json\\yaml\\yml)` |\n\n\nПодробнее про файл конфигурации [см. ниже](#custom_anchor_config_parameters)\n\nЕсли путь до конфигурации не указан, конфигурации по-умолчанию берется из файла `openapi-modifier.config.js` относительно директории запуска.\n\nМожно использовать конфиги в след. расширениях: `.ts`, `.js`, `.yaml`, `.yml`, `.json`.\n\n\u003ca name=\"custom_anchor_cli_usage\"\u003e\u003c/a\u003e\n\n### CLI\n\n```shell\nnpm i --save-dev openapi-modifier\n\nopenapi-modifier --input=input/openapi.yml --output=output/openapi.yml --config=openapi-modifier.config.js\n```\n\n[Пример использования как CLI](./examples/example-cli-openapi-yaml/package.json#L7)\n\nCLI параметры:\n\n| Опция    | Описание                                                                                                 | Пример                       | Дефолтное                                    |\n| -------- | -------------------------------------------------------------------------------------------------------- | ---------------------------- |----------------------------------------------|\n| `input`  | [**обязательный**] входной файл, специфиакция/документация в формате openapi                             | `input/openapi.yml`          |                                              |\n| `output` | [**обязательный**] выходной файл, специфиакция/документация в формате opeanpi                            | `output/openapi.yml`         |                                              |\n| `config` | путь до файла конфигурации. Детальное описание конфигурации [см. ниже](#custom_anchor_config_parameters) | `openapi-modifier.config.js` | `openapi-modifier.config.(js\\ts\\json\\yaml\\yml)` |\n\n\nПодробнее про файл конфигурации [см. ниже](#custom_anchor_config_parameters)\n\nЕсли путь до конфигурации не указан, конфигурации по-умолчанию берется из файла `openapi-modifier.config.js` относительно директории запуска.\n\nМожно использовать конфиги в след. расширениях: `.ts`, `.js`, `.yaml`, `.yml`, `.json`.\n\n\u003ca name=\"custom_anchor_package_usage\"\u003e\u003c/a\u003e\n\n### Программное использование\n\n```typescript\nimport { openapiModifier } from 'openapi-modifier';\n\n(async () =\u003e {\n    try {\n        await openapiModifier({\n            input: 'input/openapi.yml',\n            output: 'output/openapi.yml',\n            pipeline: [\n                {\n                    rule: 'remove-operation-id',\n                    config: {\n                        ignore: [],\n                    },\n                },\n            ],\n        });\n\n        process.exit(0);\n    } catch (error) {\n        console.error(error);\n        process.exit(1);\n    }\n})();\n```\n\n[Пример программного использования](./examples/example-package-openapi-yaml/generate.ts)\n\n\u003ca name=\"custom_anchor_config_parameters\"\u003e\u003c/a\u003e\n\n## Конфигурация\n\nСоздайте файл конфигурации (например, `openapi-modifier.config.js` или `openapi-modifier.config.ts`) со следующей структурой:\n\n```javascript\nmodule.exports = {\n    // (опционально) Настройки логгера\n    logger: {\n        verbose: true, // Включить подробное логирование\n        minLevel: 0    // Минимальный уровень логирования: 0 - trace, 1 - debug, 2 - info, 3 - warn, 4 - error\n    },\n    // Путь к входному файлу OpenAPI спецификации\n    input: './openapi.yaml',\n    // Путь к выходному файлу\n    output: './modified-openapi.yaml',\n    // Конвейер правил для применения (см. далее все доступные правила с примерами конфигураций)\n    pipeline: [\n        {\n            rule: \"change-content-type\",\n            disabled: false, // (опционально) Отключить правило\n            config: {\n                map: {\n                    \"*/*\": \"application/json\"\n                }\n            }\n        }\n        // Другие правила...\n    ]\n}\n```\n\n\u003e [!IMPORTANT]  \n\u003e Благодаря тому что правила выстраиваются в конвейер, вы можете:\n\u003e - редактировать следующим этапом результат предыдущего этапа, таким образом выстраивая последовательность необходимых изменений;\n\u003e - использовать правила необходимое число раз и в нужной последовательности;\n\n\u003ca name=\"custom_anchor_rule_table\"\u003e\u003c/a\u003e\n\n## Доступные правила\n\n| Правило | Краткое описание |\n|------------------------------------------------------------------| ---- |\n| [change-content-type](./src/rules/change-content-type/README-ru.md) | Изменяет типы контента (content-type) в OpenAPI спецификации в соответствии со словарем замен |\n| [change-endpoints-basepath](./src/rules/change-endpoints-basepath/README-ru.md) | Изменяет базовые пути (basepath) эндпоинтов в соответствии со словарем замен |\n| [filter-by-content-type](./src/rules/filter-by-content-type/README-ru.md) | Правило позволяет фильтровать типы содержимого (content-type) в OpenAPI спецификации. С его помощью можно явно указать, какие типы содержимого должны быть сохранены или удалены из спецификации. Правило применяется ко всем компонентам API, включая запросы, ответы и общие компоненты. |\n| [filter-endpoints](./src/rules/filter-endpoints/README-ru.md) | Правило позволяет фильтровать эндпоинты в OpenAPI спецификации на основе их путей и методов. С его помощью можно явно указать, какие эндпоинты должны быть сохранены или удалены из спецификации. Правило поддерживает как точное соответствие, так и фильтрацию по регулярным выражениям. |\n| [merge-openapi-spec](./src/rules/merge-openapi-spec/README-ru.md) | Объединяет два OpenAPI спецификации в одну. Позволяет объединить текущую спецификацию с дополнительной спецификацией из указанного файла. Поддерживает работу с файлами в форматах JSON и YAML. |\n| [patch-component-schema](./src/rules/patch-component-schema/README-ru.md) | Правило позволяет модифицировать схему компонента в OpenAPI спецификации. |\n| [patch-endpoint-parameter-schema](./src/rules/patch-endpoint-parameter-schema/README-ru.md) | Правило позволяет модифицировать схему параметров эндпоинтов в OpenAPI спецификации. |\n| [patch-endpoint-request-body-schema](./src/rules/patch-endpoint-request-body-schema/README-ru.md) | Правило для изменения схемы request body в OpenAPI спецификации. Позволяет модифицировать схему запроса для указанного эндпоинта. |\n| [patch-endpoint-response-schema](./src/rules/patch-endpoint-response-schema/README-ru.md) | Правило позволяет модифицировать схему ответа (response schema) для эндпоинтов в OpenAPI спецификации. |\n| [patch-endpoint-schema](./src/rules/patch-endpoint-schema/README-ru.md) | Правило позволяет модифицировать схему эндпоинта целиком в OpenAPI спецификации. В отличие от других правил патчинга, которые работают с отдельными частями эндпоинта (параметры, тело запроса, ответы), это правило может изменять всю структуру эндпоинта, включая все его компоненты. |\n| [remove-deprecated](./src/rules/remove-deprecated/README-ru.md) | Правило позволяет удалить устаревшие (deprecated) элементы из OpenAPI спецификации. Оно может удалять устаревшие компоненты, эндпоинты, параметры и свойства, при этом предоставляя возможность игнорировать определенные элементы и показывать описания удаляемых элементов. |\n| [remove-max-items](./src/rules/remove-max-items/README-ru.md) | Удаляет свойство `maxItems` из всех схем в OpenAPI спецификации. |\n| [remove-min-items](./src/rules/remove-min-items/README-ru.md) | Удаляет свойство `minItems` из всех схем в OpenAPI спецификации. |\n| [remove-operation-id](./src/rules/remove-operation-id/README-ru.md) | Удаляет operationId из всех операций в OpenAPI спецификации, кроме тех, что указаны в списке игнорирования |\n| [remove-parameter](./src/rules/remove-parameter/README-ru.md) | Удаляет параметр из эндпоинта в OpenAPI спецификации |\n| [remove-unused-components](./src/rules/remove-unused-components/README-ru.md) | Удаляет неиспользуемые компоненты из OpenAPI спецификации. Правило анализирует все ссылки на компоненты в документе и удаляет те, которые нигде не используются. |\n\n\n\u003ca name=\"custom_anchor_rules_description\"\u003e\u003c/a\u003e\n\n## Краткие описания правил\n\n\u003ca name=\"custom_anchor_rule_change-content-type\"\u003e\u003c/a\u003e\n\n### change-content-type\n\nИзменяет типы контента (content-type) в OpenAPI спецификации в соответствии со словарем замен\n\n#### Config\n\n| Параметр | Описание                          | Пример                     | Типизация              | Дефолтное |\n|----------|-----------------------------------|----------------------------|------------------------|-----------|\n| `map`    | [**обязательный**] Словарь замены типов контента | `{\"*/*\": \"application/json\"}` | `Record\u003cstring, string\u003e` | `{}`        |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"change-content-type\",\n            config: {\n                map: {\n                    \"*/*\": \"application/json\" // заменяем все типы контента на application/json\n                }\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"change-content-type\",\n            config: {\n                map: {\n                    \"application/xml\": \"application/json\", // заменяем application/xml на application/json\n                    \"text/plain\": \"application/json\", // заменяем text/plain на application/json\n                    \"*/*\": \"application/json\" // заменяем все остальные типы контента на application/json\n                }\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило change-content-type](./src/rules/change-content-type/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_change-endpoints-basepath\"\u003e\u003c/a\u003e\n\n### change-endpoints-basepath\n\nИзменяет базовые пути (basepath) эндпоинтов в соответствии со словарем замен\n\n#### Config\n\n| Параметр                    | Описание                                                              | Пример               | Типизация                | Дефолтное |\n|-----------------------------|-----------------------------------------------------------------------|----------------------|--------------------------|-----------|\n| `map`                       | [**обязательный**] Словарь замены путей                                     | `{\"/api/v1\": \"/v1\"}` | `Record\u003cstring, string\u003e` | `{}`      |\n| `ignoreOperationCollisions` | Игнорировать возникающие коллизии endpoint'ов после применения замены | `true`               | `boolean`                | `false`        |\n\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"change-endpoints-basepath\",\n            config: {\n               map: { \n                   '/public/api': '', // удаляем префикс /public/api из всех путей\n               },\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"change-endpoints-basepath\",\n            config: {\n               map: { \n                   '/public/v1/service/api': '/api', // заменяем префикс /public/v1/service/api на /api\n               }, \n               ignoreOperationCollisions: false, // не игнорируем конфликты операций при замене путей\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило change-endpoints-basepath](./src/rules/change-endpoints-basepath/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_filter-by-content-type\"\u003e\u003c/a\u003e\n\n### filter-by-content-type\n\nПравило позволяет фильтровать типы содержимого (content-type) в OpenAPI спецификации. С его помощью можно явно указать, какие типы содержимого должны быть сохранены или удалены из спецификации. Правило применяется ко всем компонентам API, включая запросы, ответы и общие компоненты.\n\n#### Config\n\n| Параметр   | Описание                                             | Пример                 | Типизация       | Дефолтное |\n|------------|------------------------------------------------------|------------------------|-----------------|--------|\n| `enabled`  | [**опциональный**] Список разрешенных content-type. Если не указан, сохраняются все типы, не указанные в `disabled` | `['application/json']` | `Array\u003cstring\u003e` |        |\n| `disabled` | [**опциональный**] Список запрещенных content-type   | `['multipart/form-data']` | `Array\u003cstring\u003e` |        |\n\nПримеры конфигураций:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-by-content-type\",\n            config: {\n                enabled: ['application/json'], // оставить только content-type application/json, удалить все остальные\n            }\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-by-content-type\",\n            config: {\n                disabled: ['multipart/form-data'], // удалить content-type multipart/form-data, оставить все остальные\n            }\n        }\n        // ... other rules\n    ]\n}\n```\n\n\u003e [!IMPORTANT]\n\u003e 1. Если указаны оба параметра `enabled` и `disabled`, сначала применяется фильтр `enabled`, затем `disabled`\n\u003e 2. Правило выводит предупреждения для content-type, указанных в конфигурации, но не найденных в спецификации\n\n[Подрбонее про правило filter-by-content-type](./src/rules/filter-by-content-type/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_filter-endpoints\"\u003e\u003c/a\u003e\n\n### filter-endpoints\n\nПравило позволяет фильтровать эндпоинты в OpenAPI спецификации на основе их путей и методов. С его помощью можно явно указать, какие эндпоинты должны быть сохранены или удалены из спецификации. Правило поддерживает как точное соответствие, так и фильтрацию по регулярным выражениям.\n\n#### Config\n\n\u003e [!IMPORTANT]  \n\u003e Правило работает либо в режиме enabled - фильтрации endpoint'ов из спецификации (когда указан в конфигурации либо `enabled`, либо `enabledPathRegExp`), либо в disabled - исключения endpoint'ов из спецификации (когда указан в конфигурации либо `disabled`, либо `disabledPathRegExp`)\n\n| Параметр                | Описание                                                                                                                                                                               | Пример                | Типизация       | Дефолтное       |\n|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|-----------------|-----------------|\n| `enabled`               | Список эндпоинтов, которые нужно оставить | `[{\"method\": \"GET\", \"path\": \"/pets\"}]` | `Array\u003cstring \\ { path: string; method: string }\u003e` | - |\n| `enabledPathRegExp`     | Список регулярных выражений для путей, которые нужно оставить | `[/^\\/api\\/v1/]` | `Array\u003cRegExp\u003e` | - |\n| `disabled`              | Список эндпоинтов, которые нужно исключить | `[{\"method\": \"POST\", \"path\": \"/pets\"}]` | `Array\u003cstring \\ { path: string; method: string }\u003e` | - |\n| `disabledPathRegExp`    | Список регулярных выражений для путей, которые нужно исключить | `[/^\\/internal/]` | `Array\u003cRegExp\u003e` | - |\n| `printIgnoredEndpoints` | Выводить ли в лог информацию об исключенных эндпоинтах | `true` | `boolean` | `false` |\n\nПримеры конфигураций:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-endpoints\",\n            config: {\n                enabled: [\n                    'GET /foo/ping' // оставляем только эндпоинт GET /foo/ping, все остальные будут удалены\n                ],\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-endpoints\",\n            config: {\n                enabledPathRegExp: [\n                    /\\/public/ // оставляем все эндпоинты, путь которых содержит /public\n                ],\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-endpoints\",\n            config: {\n                disabled: [\n                    'GET /foo/ping' // удаляем эндпоинт GET /foo/ping, все остальные остаются\n                ],\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"filter-endpoints\",\n            config: {\n                disabledPathRegExp: [\n                    /\\/internal/ // удаляем все эндпоинты, путь которых содержит /internal\n                ],\n                printIgnoredEndpoints: true, // выводим в консоль информацию об удаленных эндпоинтах\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило filter-endpoints](./src/rules/filter-endpoints/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_merge-openapi-spec\"\u003e\u003c/a\u003e\n\n### merge-openapi-spec\n\nОбъединяет два OpenAPI спецификации в одну. Позволяет объединить текущую спецификацию с дополнительной спецификацией из указанного файла. Поддерживает работу с файлами в форматах JSON и YAML.\n\n#### Config\n\n| Параметр                    | Описание                                                                                                                                                                                                                                                                                                                                          | Пример                                       | Типизация | Дефолтное |\n|-----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------|----------|-----------|\n| `path`                      | [**обязательный**] Путь до OpenAPI конфигурации, которую необходимо подлить в текущую спецификацию. Путь может быть относительный (относительно расположения package.json), либо абсолютный (например полученный через `__dirname` относительно нахождения конфига). Применимы форматы: `*.json`, `*.yml`, `*.yaml`.                              | `temp-openapi-specs/new-list-endpoints.yaml` | `string` |           |\n| `ignoreOperationCollisions` | При слиянии нескольких спецификаций могут происходить конфликты, когда есть индентичные endpoint'ы. По умолчанию, инструмент запрещает влитие если находятся коллизии, для предотвращения не предвиденных изменений в исходной спецификации. Данной настройкой можно проигнорировать конфликты и все равно слить спецификации.                    | `true`                                       | `boolean` | `false`   |\n| `ignoreComponentCollisions` | При слиянии нескольких спецификаций могут происходить конфликты, когда есть индентичные общие компоненты спецификаций. По умолчанию, инструмент запрещает влитие если коллизии находятся, для предотвращения не предвиденных изменений в исходной спецификации. Данной настройкой можно проигнорировать конфликты и все равно слить спецификации. | `true`                                       | `boolean` | `false`   |\n\n\u003e [!IMPORTANT]\n\u003e **Если необходимо объединить несколько спецификаций**, вы можете использовать несколько раз данное правило в общем пайлайне конфигурации.\n\nПримеры конфигураций:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"merge-openapi-spec\",\n            config: {\n                path: 'temp-openapi-specs/new-list-endpoints.yaml', // указываем путь к файлу спецификации для слияния\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"merge-openapi-spec\",\n            config: {\n                path: __dirname + '../temp-openapi-specs/new-list-endpoints.json', // указываем абсолютный путь к файлу спецификации\n                ignoreOperationCollisions: true, // игнорируем конфликты операций при слиянии\n                ignoreComponentCollisions: true, // игнорируем конфликты компонентов при слиянии\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило merge-openapi-spec](./src/rules/merge-openapi-spec/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_patch-component-schema\"\u003e\u003c/a\u003e\n\n### patch-component-schema\n\nПравило позволяет модифицировать схему компонента в OpenAPI спецификации.\n\n#### Config\n\n| Параметр    | Описание                                                                                 | Пример                                                                       | Типизация                                 | Дефолтное                                |\n| -------- |------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|-------------------------------------------|------------------------------------------|\n| `descriptor`  | [**обязательный**] Описание компонента для модификации. [Подробнее про различия между простым и объектным дескриптором компонента с коррекцией](./docs/descriptor-ru.md) | `\"Pet.name\"` или `{\"componentName\": \"Pet\", \"correction\": \"properties.name\"}` | `string \\ { componentName: string; correction: string }` | - |\n| `patchMethod`  | Метод применения патча. [Подробнее про различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md)  | `\"merge\"`                                                                    | `\"merge\" \\ \"deepmerge\"`                   | `\"merge\"` |\n| `schemaDiff`  | [**обязательный**] Схема для патча. [Подробные примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)                          | `{\"type\": \"string\", \"description\": \"New description\"}`                       | `OpenAPISchema`                           | -                                        |\n\n\u003e [!IMPORTANT]\n\u003e Тонкости задачния параметра `descriptor`:\n\u003e - не предусмотрен переход по $ref'ам. Потому что может вызвать не преднамеренное изменение в общих компонентах, и тем самым создать не ожиданное изменение в другом месте спецификации. В таком случае лучше модифицировать напрямую ту сущность на которую ссылается $ref;\n\u003e - если необходим переход по элементам массива - нужно доуточнение в `descriptor` (соотвтественно `[]`), например, `TestSchemaDTO[].test`\n\u003e - если необходим переход по oneOf, allOf, anyOf нужно доуточнение в `descriptor` (соотвтественно `oneOf[{number}]`, `allOf[{number}]` или `anyOf[{number}]`), например, `TestObjectDTO.oneOf[1].TestSchemaDTO`, `TestObjectDTO.allOf[1].TestSchemaDTO` или  `TestObjectDTO.anyOf[1].TestSchemaDTO`;\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-component-schema\",\n            config: {\n                descriptor: 'TestDTO', // указываем компонент, который нужно изменить\n                schemaDiff: {\n                    type: 'string', // меняем тип компонента на string\n                },\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-component-schema\",\n            config: {\n                descriptor: 'TestObjectDTO.oneOf[0].TestArraySchemaDTO[]', // указываем путь к компоненту в сложной структуре\n                schemaDiff: {\n                    type: 'string', // меняем тип компонента на string\n                    enum: ['foo', 'bar'], // добавляем enum к компоненту\n                },\n                patchMethod: 'deepmerge', // используем метод deepmerge для глубокого слияния изменений\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило patch-component-schema](./src/rules/patch-component-schema/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_patch-endpoint-parameter-schema\"\u003e\u003c/a\u003e\n\n### patch-endpoint-parameter-schema\n\nПравило позволяет модифицировать схему параметров эндпоинтов в OpenAPI спецификации.\n\n#### Config\n\n| Параметр              | Описание                                                                                                               | Пример                                                                                                                                                                 | Типизация                                                                           | Дефолтное    |\n|-----------------------|------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|--------------|\n| `endpointDescriptor`  | [**обязательный**] Указание в каком endpoint нужно поменять схему параметра запроса.                                   | `'GET /api/list'`                                                                                                                                                     | `string \\ { path: string; method: string }`                                                                            |              |\n| `parameterDescriptor` | [**обязательный**] Указание какой параметр запроса, на который ссылается `endpointDescriptor`, нужно поменять.         | `'TestSchemaDTO'`, `'TestSchemaDTO.test'`, `'TestSchemaDTO[].testField'`,  `'TestObjectDTO.oneOf[1]'`, `'TestObjectDTO.allOf[1]'` или  `'TestObjectDTO.anyOf[1].testField'`        | `string`                                                                            |              |\n| `schemaDiff`          | Изменения для схемы параметра [Подробные примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)                                                              | `{type: \"number\"}`                                                                                                   | `OpenAPISchema`                                                                     |              |\n| `objectDiff`          | Изменения для самого параметра                                                                                         | `{ required: true }`                                                                                                    | `{name?: string; in?: 'query' / 'header' / 'path' / 'cookie'; required?: boolean;}` |              |\n| `patchMethod`         | Метод применения изменений, указанных в `objectDiff` и `schemaDiff`. [Подробнее про различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md) | `\"merge\"` | `\"merge\" \\ \"deepmerge\"` | `\"merge\"` |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-parameter-schema\",\n            config: {\n                endpointDescriptor: 'GET /api/list', // указываем эндпоинт, который нужно изменить\n                parameterDescriptor: {\n                    name: 'test', // указываем имя параметра\n                    in: 'query', // указываем, что параметр находится в query\n                },\n                schemaDiff: {\n                    enum: ['foo', 'bar'], // добавляем enum к параметру\n                }\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-parameter-schema\",\n            config: {\n                endpointDescriptor: 'GET /api/list', // указываем эндпоинт, который нужно изменить\n                parameterDescriptor: {\n                    name: 'test', // указываем имя параметра\n                    in: 'query', // указываем, что параметр находится в query\n                },\n                schemaDiff: {\n                    type: 'string', // меняем тип параметра на string\n                    enum: ['foo', 'bar'], // добавляем enum к параметру\n                },\n                objectDiff: {\n                    name: 'newTest',\n                    in: 'query',\n                    required: true, // делаем параметр обязательным\n                },\n                patchMethod: 'deepmerge' // используем метод deepmerge для глубокого слияния изменений\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило patch-endpoint-parameter-schema](./src/rules/patch-endpoint-parameter-schema/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_patch-endpoint-request-body-schema\"\u003e\u003c/a\u003e\n\n### patch-endpoint-request-body-schema\n\nПравило для изменения схемы request body в OpenAPI спецификации. Позволяет модифицировать схему запроса для указанного эндпоинта.\n\n#### Config\n\n| Параметр                    | Описание                                                                                                                                                | Пример                                                                                                                                                                | Типизация      | Дефолтное |\n|-----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------|-----------|\n| `endpointDescriptor`        | [**обязательный**] Указание в каком endpoint нужно поменять схему параметра запроса.                                                                    | `'GET /api/list'`                                                                                                                                                     | `string \\ { path: string; method: string }`       |           |\n| `contentType`               | Указание к какому типу запросов (content-type) endpoint'а нужно применить изменение. При отсутствии значения, будут изменены все варианты типов запросов. | `'application/json'`                                                                                                                                                  | `string`       |  |\n| `correction`                | Путь к полю в схеме для модификации                                                                                                                     | `\"name\"` | `string` | - |\n| `schemaDiff`                | [**обязательный**] Изменения для применения к схеме. [Подробные примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)                                                                                                                          | `{type: \"number\"}`                                                                                                 | `OpenAPISchema` |           |\n| `patchMethod`               | Метод применения изменений [Подробнее про различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md) | `\"merge\"` | `\"merge\" \\ \"deepmerge\"` | `\"merge\"` |\n\nПримеры конфигураций:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-request-body-schema\",\n            config: {\n                endpointDescriptor: 'POST /api/order', // указываем эндпоинт, который нужно изменить\n                correction: \"status\", // указываем путь к полю status в теле запроса\n                schemaDiff: {\n                    enum: ['foo', 'bar'], // добавляем enum к полю status\n                },\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-request-body-schema\",\n            config: {\n                endpointDescriptor: 'POST /api/order', // указываем эндпоинт, который нужно изменить\n                contentType: \"application/json\", // указываем тип контента, для которого применяем изменения\n                schemaDiff: {\n                    properties: {\n                        testField: {\n                            type: 'number', // меняем тип поля testField на number\n                        },\n                    },\n                },\n                patchMethod: \"deepmerge\" // используем метод deepmerge для глубокого слияния изменений\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nили\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-request-body-schema\",\n            config: {\n                endpointDescriptor: 'POST /api/orders',\n                correction: '[].status',\n                schemaDiff: {\n                    enum: ['foo', 'bar'],\n                },\n                patchMethod: \"deepmerge\"\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило patch-endpoint-request-body-schema](./src/rules/patch-endpoint-request-body-schema/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_patch-endpoint-response-schema\"\u003e\u003c/a\u003e\n\n### patch-endpoint-response-schema\n\nПравило позволяет модифицировать схему ответа (response schema) для эндпоинтов в OpenAPI спецификации.\n\n#### Config\n\n| Параметр                | Описание                                                                                                                                            | Пример                                                                                                                                                                   | Типизация       | Дефолтное |\n|-------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------|-----------|\n| `endpointDescriptor`    | [**обязательный**] Указание в каком endpoint нужно поменять схему параметра запроса.                                                                | `'GET /api/list'`                                                                                                                                                        | `string \\ { path: string; method: string }`        |           |\n| `correction`            | Путь к свойству схемы для модификации                                                                                                               | `\"status\"`                                                                                                                                                               | `string` | - |\n| `code`                  | Указание к какому статус коду ответа нужно применить изменение. При отсутствии значения, будет применен к первому 2xx ответу.                       | `200`                                                                                                                                                                    | `number`        |  |\n| `contentType`           | Указание к какому типу ответа (content-type) endpoint нужно применить изменение. При отсутствии значения, будут изменены все варианты типов ответов. | `'application/json'`                                                                                                                                                     | `string`        |  |\n| `schemaDiff`            | [**обязательный**] Необходимое изменение в формате OpenAPI. [Подробные примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)                                                             | `{type: \"number\"}`                                                                                                  | `OpenAPISchema` |           |\n| `patchMethod`           | Метод применения изменений [Подробнее про различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md)                                                                        | `\"merge\"` | `\"merge\" \\ \"deepmerge\"` | `\"merge\"` |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-response-schema\",\n            config: {\n                endpointDescriptor: 'GET /api/list', // указываем эндпоинт, который нужно изменить\n                correction: '[].status', // указываем путь к полю status в массиве ответа\n                schemaDiff: {\n                    enum: ['foo', 'bar'], // добавляем enum к полю status\n                },\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"patch-endpoint-response-schema\",\n            config: {\n                endpointDescriptor: 'GET /api/list', // указываем эндпоинт, который нужно изменить\n                correction: '[].status', // указываем путь к полю status в массиве ответа\n                code: 200, // указываем код ответа, для которого применяем изменения\n                contentType: 'application/json', // указываем тип контента, для которого применяем изменения\n                schemaDiff: {\n                    enum: ['foo', 'bar'], // добавляем enum к полю status\n                },\n                patchMethod: 'deepmerge' // используем метод deepmerge для глубокого слияния изменений\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило patch-endpoint-response-schema](./src/rules/patch-endpoint-response-schema/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_patch-endpoint-schema\"\u003e\u003c/a\u003e\n\n### patch-endpoint-schema\n\nПравило позволяет модифицировать схему эндпоинта целиком в OpenAPI спецификации. В отличие от других правил патчинга, которые работают с отдельными частями эндпоинта (параметры, тело запроса, ответы), это правило может изменять всю структуру эндпоинта, включая все его компоненты.\n\n#### Config\n\n| Параметр                       | Описание                                               | Пример | Типизация | Дефолтное     |\n|--------------------------------|--------------------------------------------------------|---------|------------|---------------|\n| `endpointDescriptor`           | [**обязательный**] Описание эндпоинта для патчинга     | `{ path: \"/pets\", method: \"get\" }` | `{ path: string, method: string }` | -             |\n| `endpointDescriptorCorrection` | Путь к конкретному полю в схеме эндпоинта для патчинга | `\"responses.200.content.application/json.schema\"` | `string` | -             |\n| `schemaDiff`                   | [**обязательный**] Необходимое изменение в формате OpenAPI. [Подробные примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)              | `{ type: \"object\", properties: { ... } }` | `OpenAPISchema` | -             |\n| `patchMethod`                    | Метод применения изменений [Подробнее про различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md)                                                                       | `\"merge\"` | `\"merge\" \\ \"deepmerge\"` | `\"merge\"` |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        {\n            rule: \"patch-endpoint-schema\",\n            config: {\n                endpointDescriptor: \"GET /pets\", // указываем эндпоинт, который нужно изменить\n                patchMethod: \"merge\", // используем метод merge для применения изменений\n                schemaDiff: {\n                    \"security\": [ // добавляем секцию security к схеме\n                        {\n                            \"bearerAuth\": []\n                        }\n                    ]\n                }\n            }\n        }\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        {\n            rule: \"patch-endpoint-schema\",\n            config: {\n                patchMethod: 'merge',\n                endpointDescriptor: \"GET /pets\",\n                endpointDescriptorCorrection: 'responses.200.content.*/*.schema',\n                schemaDiff: {\n                    enum: ['3', '4'],\n                },\n            }\n        }\n    ]\n}\n```\n\n[Подрбонее про правило patch-endpoint-schema](./src/rules/patch-endpoint-schema/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-deprecated\"\u003e\u003c/a\u003e\n\n### remove-deprecated\n\nПравило позволяет удалить устаревшие (deprecated) элементы из OpenAPI спецификации. Оно может удалять устаревшие компоненты, эндпоинты, параметры и свойства, при этом предоставляя возможность игнорировать определенные элементы и показывать описания удаляемых элементов.\n\n#### Config\n\n| Параметр | Описание                                                                                                                | Пример | Типизация | Дефолтное |\n|----------|-------------------------------------------------------------------------------------------------------------------------|---------|-----------|-----------|\n| `ignoreComponents` | [**опциональный**] Список компонентов, которые не должны быть удалены, даже если они помечены как устаревшие            | `[{\"componentName\": \"Pet\"}]` | `Array\u003c{ componentName: string }\u003e` | `[]` |\n| `ignoreEndpoints` | [**опциональный**] Список эндпоинтов, которые не должны быть удалены, даже если они помечены как устаревшие             | `[\"GET /pets\"]` | `Array\u003cstring \\ { path: string; method: string }\u003e` | `[]` |\n| `ignoreEndpointParameters` | [**опциональный**] Список параметров эндпоинтов, которые не должны быть удалены, даже если они помечены как устаревшие  | `[{\"path\": \"/pets\", \"method\": \"get\", \"name\": \"limit\", \"in\": \"query\"}]` | `Array\u003c{ path: string; method: string; name: string; in: \"query\" \\ \"path\" \\ \"header\" \\ \"cookie\" }\u003e` | `[]` |\n| `showDeprecatedDescriptions` | [**опциональный**] Показывать ли описания удаляемых устаревших элементов в логах, полезно для пояснения, что нужно использовать вместо них | `true` | `boolean` | `false` |\n\n\u003e [!IMPORTANT]  \n\u003e Учитываются только локальные $ref'ы файла, вида: `#/...`\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        {\n            rule: \"remove-deprecated\",\n            config: {},\n        }\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        {\n            rule: \"remove-deprecated\",\n            config: {\n                ignoreComponents: [\n                    { componentName: \"Pet\" } // сохраняем компонент Pet даже если он помечен как устаревший\n                ],\n                ignoreEndpoints: [\n                    { path: \"/pets\", method: \"get\" } // сохраняем GET /pets даже если он помечен как устаревший\n                ],\n                ignoreEndpointParameters: [\n                    { path: \"/pets\", method: \"get\", name: \"limit\", in: \"query\" } // сохраняем параметр limit в GET /pets даже если он помечен как устаревший\n                ],\n                showDeprecatedDescriptions: true // выводим в консоль описания удаленных устаревших элементов\n            },\n        }\n    ]\n}\n```\n\n[Подрбонее про правило remove-deprecated](./src/rules/remove-deprecated/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-max-items\"\u003e\u003c/a\u003e\n\n### remove-max-items\n\nУдаляет свойство `maxItems` из всех схем в OpenAPI спецификации.\n\n#### Config\n\n| Параметр    | Описание                          | Пример                     | Типизация              | Дефолтное |\n| -------- |-----------------------------------|----------------------------|------------------------|-----------|\n| `showUnusedWarning`  | [**опциональный**] Показывать предупреждение, если не найдено схем с maxItems | `true` | `boolean` | `false`        |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-max-items\",\n            config: {} // удалить свойство maxItems из всех схем, не показывать предупреждения\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-max-items\",\n            config: {\n                showUnusedWarning: true // показать предупреждение, если в спецификации не найдены схемы с maxItems\n            }\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило remove-max-items](./src/rules/remove-max-items/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-min-items\"\u003e\u003c/a\u003e\n\n### remove-min-items\n\nУдаляет свойство `minItems` из всех схем в OpenAPI спецификации.\n\n#### Config\n\n| Параметр    | Описание                          | Пример                     | Типизация              | Дефолтное |\n| -------- |-----------------------------------|----------------------------|------------------------|-----------|\n| `showUnusedWarning`  | [**опциональный**] Показывать предупреждение, если не найдено схем с `minItems` | `true` | `boolean` | `false`        |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-min-items\",\n            config: {} // удалить свойство minItems из всех схем, не показывать предупреждения\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-min-items\",\n            config: {\n                showUnusedWarning: true // показать предупреждение, если в спецификации не найдены схемы с minItems\n            }\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило remove-min-items](./src/rules/remove-min-items/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-operation-id\"\u003e\u003c/a\u003e\n\n### remove-operation-id\n\nУдаляет operationId из всех операций в OpenAPI спецификации, кроме тех, что указаны в списке игнорирования\n\n#### Config\n\n| Параметр    | Описание                          | Пример                     | Типизация              | Дефолтное |\n| -------- |-----------------------------------|----------------------------|------------------------|-----------|\n| `ignore`  | [**опциональный**] Список operationId для игнорирования | `[\"getPets\", \"createPet\"]` | `string[]` | `[]` |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-operation-id\",\n            config: {} // удалить все атрибуты operationId из эндпоинтов\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-operation-id\",\n            config: {\n                ignore: [\"getPets\", \"createPet\"], // сохранить operationId для этого эндпоинта\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило remove-operation-id](./src/rules/remove-operation-id/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-parameter\"\u003e\u003c/a\u003e\n\n### remove-parameter\n\nУдаляет параметр из эндпоинта в OpenAPI спецификации\n\n#### Config\n\n| Параметр    | Описание                                                                                                                                  | Пример                     | Типизация              | Дефолтное |\n| -------- |-------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|------------------------|-----------|\n| `endpointDescriptor`  | [**обязательный**] Описание эндпоинта, из которого нужно удалить параметр                                                                 | `\"GET /pets\"` | `string \\ { path: string; method: string }` | -         |\n| `parameterDescriptor`  | [**обязательный**] Описание параметра, который нужно удалить. В параметр `in` можно указать: `\"query\"`, `\"path\"`, `\"header\"`, `\"cookie\"`. | `{\"name\": \"petId\", \"in\": \"path\"}` | `{ name: string; in: \"query\" \\ \"path\" \\ \"header\" \\ \"cookie\" }` | -         |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-parameter\",\n            config: {\n                endpointDescriptor: \"GET /pets/{petId}\", // указать конечную точку, из которой нужно удалить параметр\n                parameterDescriptor: {\n                    name: \"version\", // указать имя удаляемого параметра\n                    in: \"query\" // указать местоположение параметра (параметр запроса)\n                }\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило remove-parameter](./src/rules/remove-parameter/README-ru.md)\n\n----------------------\n\n\u003ca name=\"custom_anchor_rule_remove-unused-components\"\u003e\u003c/a\u003e\n\n### remove-unused-components\n\nУдаляет неиспользуемые компоненты из OpenAPI спецификации. Правило анализирует все ссылки на компоненты в документе и удаляет те, которые нигде не используются.\n\n#### Config\n\n| Параметр    | Описание                          | Пример            | Типизация              | Дефолтное |\n| -------- |-----------------------------------|-------------------|------------------------|-----------|\n| `ignore`  | [**опциональный**] Список компонентов или регулярных выражений, которые нужно игнорировать при удалении | `[\"NotFoundDTO\", \"/^Error.*/\"]` | `Array\u003cstring \\| RegExp\u003e` | `[]` |\n| `printDeletedComponents` | [**опциональный**] Если true, то в консоль будет выведен список удаленных компонентов | `true` | `boolean` | `false` |\n\nПример конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-unused-components\",\n            config: {},\n        }\n        // ... other rules\n    ]\n}\n```\n\nПример более детальной конфигурации:\n\n```js\nmodule.exports = {\n    pipeline: [\n        // ... other rules\n        {\n            rule: \"remove-unused-components\",\n            config: {\n                ignore: [\n                    \"NotFoundDTO\",\n                    /^Error.*/, // игнорировать все компоненты, начинающиеся с Error\n                    /.*Response$/ // игнорировать все компоненты, заканчивающиеся на Response\n                ],\n                printDeletedComponents: true // выводить список удаленных компонентов в консоль\n            },\n        }\n        // ... other rules\n    ]\n}\n```\n\n[Подрбонее про правило remove-unused-components](./src/rules/remove-unused-components/README-ru.md)\n\n## FAQ\n\n- **Чем опасны модификации по ссылкам $ref?** Потому что значит что $ref ссылается на общую часть схемы, и ее модификация, возможно, приведет к неявному изменению в другом месте спецификации, где переиспользуется $ref, и такую багу будет крайне сложно отловить.\n\n## AI инструменты\n\n- [DeepWiki документация](https://deepwiki.com/itwillwork/openapi-modifier)\n- [Context7 документация для LLM моделей и AI редакторов кода](https://context7.com/itwillwork/openapi-modifier)\n\n## Примеры использования\n\nВ директории `examples` вы можете найти различные примеры использования пакета:\n\n- [example-cli-generate-api-types](./examples/example-cli-generate-api-types) - Пример генерации типов API с использованием CLI\n- [example-cli-openapi-json](./examples/example-cli-openapi-json) - Пример работы с JSON форматом OpenAPI через CLI\n- [example-cli-openapi-yaml](./examples/example-cli-openapi-yaml) - Пример работы с YAML форматом OpenAPI через CLI\n- [example-cli-openapi-yaml-to-json](./examples/example-cli-openapi-yaml-to-json) - Пример конвертации YAML в JSON формат\n- [example-cli-simple-generate-api-types](./examples/example-cli-simple-generate-api-types) - Простой пример генерации типов API\n- [example-cli-simple-json-config](./examples/example-cli-simple-json-config) - Пример использования JSON конфигурации\n- [example-cli-simple-npx](./examples/example-cli-simple-npx) - Пример использования через npx\n- [example-package-openapi-yaml](./examples/example-package-openapi-yaml) - Пример программного использования пакета\n\nКаждый пример содержит:\n- Входные файлы OpenAPI спецификации\n- Конфигурационные файлы\n- Скрипты для запуска\n- Результирующие файлы\n\n## Дополнительные полезные ссылки\n\n- [Добавление нового правила](./docs/contributing-ru.md)\n- [Различия между простым и объектным дескриптором компонента с коррекцией](./docs/descriptor-ru.md)\n- [Различия между методами merge и deepmerge](./docs/merge-vs-deepmerge-ru.md)\n- [Примеры спецификаций для OpenAPI](./docs/schema-diff-ru.md)\n- [Simple Text File Modifier](./docs/simple-text-file-modifier-ru.md)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fitwillwork%2Fopenapi-modifier","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fitwillwork%2Fopenapi-modifier","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fitwillwork%2Fopenapi-modifier/lists"}