openapi-format

repository·main·Indexed 41 days ago

https://github.com/thim81/openapi-format

A CLI and module for standardizing OpenAPI documents through field ordering, casing enforcement, element filtering, and document splitting. Version 1.33.7 supports converting between OpenAPI versions 3.0/3.1 to 3.1/3.2, removing unused components, and applying custom overlays to maintain consistent API specifications.

Tokens
23.4K
Snippets
74
Records
107
Agent score
51%

What's inside openapi-format

  1. Overview of openapi-format

    main

    openapi-format is a tool for formatting OpenAPI documents by ordering fields, applying casing rules, filtering elements, and applying overlays. It helps standardize OpenAPI specifications for public documentation, maintenance, and CI/CD pipelines.

    Key Capabilities:

    • Ordering: Sort OpenAPI fields hierarchically or alphabetically.
    • Formatting: Apply casing (camelCase, PascalCase, etc.) and clean indentation for JSON/YAML.
    • Filtering: Remove specific elements like internal endpoints, beta tags, or unused components based on methods, tags, or operationIDs.
    • Transformation: Split large documents into multi-file structures, bundle references, or convert between OpenAPI versions (3.0/3.1 to 3.1/3.2).
    • Customization: Use OpenAPI Overlays to extend or customize existing documents.
  2. Perform text search and replace

    main

    The textReplace option allows you to perform a global search and replace for text within the OpenAPI specification's description, summary, and url fields.

    # Example: Replace specific terms
    textReplace:
      - searchFor: 'Pets'
        replaceWith: 'Dogs'
      - searchFor: 'swagger.io'
        replaceWith: 'openapis.org'
  3. Filter by operationIds

    main

    Use operationIds to remove specific fields and attached fields that match the provided operationId values. Use inverseOperationIds to keep only the specified operation IDs.

    # Example: Removing specific operationId
    operationIds:
      - findPetsByStatus
      - updatePet
  4. Preserve empty objects

    main

    By default, openapi-format removes empty objects, except for those within examples, security, schemas, default, oneOf, or allOf.

    • Set preserveEmptyObjects: true to keep all empty objects.
    • Pass an array of keys (e.g., ['schema']) to only prevent removal of empty objects for those specific keys.
    # Example: Only preserve empty objects if they are under the 'schema' key
    preserveEmptyObjects:
      - schema
  5. Apply OpenAPI Overlays to modify specifications

    main

    An OpenAPI Overlay allows you to dynamically update, add, or remove fields in an OAS using JSONPath targets. Use the --overlayFile option to apply an overlay.

    Overlay Structure: An overlay file (recommended extension .overlay.yaml) follows the OpenAPI Overlay Specification 1.1.0 and includes actions with target, update, remove, or copy keys.

    Using extends: An overlay can define its base document using the extends property (supporting local paths or URLs). If extends is used, the input file argument in the CLI becomes optional.

    Example Overlay (overlay.yaml):

    overlay: 1.1.0
    info:
      title: Example Overlay
      version: 1.0.0
    actions:
      - target: "$"
        update:
          info:
            description: "Updated description"
      - target: "$.paths['/example'].get.parameters"
        remove: true
      - target: "$.info.title"
        copy: "$.info.version"
    # Apply an overlay to a local file
    openapi-format openapi.yaml --overlayFile overlay.yaml -o openapi-updated.yaml
    
    # Apply an overlay that uses the 'extends' property (no input file needed)
    openapi-format --overlayFile overlay.yaml -o openapi-updated.yaml
  6. Strip custom flags

    main

    The stripFlags option removes the custom flag property itself from a field, but leaves the parent field and its other properties intact. This is different from flags, which removes the entire field containing the flag.

    # Example: Remove the 'x-exclude' key but keep the rest of the operation
    stripFlags:
      - x-exclude
  7. Configure OpenAPI field sorting

    main

    The CLI sorts the OpenAPI document based on a defined order for specific keys/fields. Fields not explicitly defined in your configuration will retain their original order from the source document. You can provide a custom ordering file using the --sortFile (or -s) flag.

    By default, the tool uses defaultSort.json.

    | Key         | Ordered by                                                                       | OpenAPI reference                                                               |
    |-------------|----------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
    | root        | - openapi\n\- info\n\- servers\n\- paths\n\- components\n\- tags\n\- x-tagGroups\n\- externalDocs | [openapi-object](https://spec.openapis.org/oas/v3.0.3.html#openapi-object) |
    | get         | - operationId\n\- summary\n\- description\n\- parameters\n\- requestBody\n\- responses                | [operationObject](https://spec.openapis.org/oas/v3.0.3.html#operationObject) |
    | post        | - operationId\n\- summary\n\- description\n\- parameters\n\- requestBody\n\- responses                | [operationObject](https://spec.openapis.org/oas/v3.0.3.html#operationObject) |
    | put         | - operationId\n\- summary\n\- description\n\- parameters\n\- requestBody\n\- responses                | [operationObject](https://spec.openapis.org/oas/v3.0.3.html#operationObject) |
    | patch       | - operationId\n\- summary\n\- description\n\- parameters\n\- requestBody\n\- responses                | [operationObject](https://spec.openapis.org/oas/v3.0.3.html#operationObject) |
    | delete      | - operationId\n\- summary\n\- description\n\- parameters\n\- requestBody\n\- responses                | [operationObject](https://spec.openapis.org/oas/v3.0.3.html#operationObject) |
    | parameters  | - name\n\- in\n\- description\n\- required\n\- schema                                         | [parameterObject](https://spec.openapis.org/oas/v3.0.3.html#parameterObject) |
    | requestBody | - description\n\- headers\n\- content\n\- links                                         | [request-body-object](https://spec.openapis.org/oas/v3.0.3.html#request-body-object) |
    | responses   | - description\n\- headers\n\- content\n\- links                                         | [responses-object](https://spec.openapis.org/oas/v3.0.3.html#responses-object) |
    | content     | (By alphabet)                                                                    | [responses-object](https://spec.openapis.org/oas/v3.0.3.html#responses-object) |
    | components  | - parameters\n\- schemas                                                         | [components-object](https://spec.openapis.org/oas/v3.0.3.html#components-object) |
    | schema      | - description\n\- type\n\- items\n\- properties\n\- format\n\- example\n\- default          | [schemaObject](https://spec.openapis.org/oas/v3.0.3.html#schemaObject) |
    | schemas     | - description\n\- type\n\- items\n\- properties\n\- format\n\- example\n\- default                         |                                                                  |
    | properties  | - description\n\- type\n\- items\n\- format\n\- example\n\- default\n\- enum                            |                                                                  |
  8. Filter by request and response content types

    main

    Control which media types are present in your OpenAPI document:

    • responseContent: Removes content from the Response Object that matches the specified media types.
    • inverseResponseContent: Keeps only the specified media types in responses.
    • requestContent: Removes content from the Request Body Object that matches the specified media types.
    • inverseRequestContent: Keeps only the specified media types in request bodies.
    # Example: Removing application/json from responses
    responseContent:
      - application/json
  9. Filter by operations using wildcards

    main

    The operations filter allows targeting specific combinations of HTTP methods and paths using the format METHOD::/path. This is useful when operationId is not available. It supports wildcards:

    • Strict matching: "GET::/pets" targets only the GET method on /pets.
    • Method wildcard: "*::/pets" targets all methods on /pets.
    • Path wildcard: "GET::/pets/*" targets the GET method on /pets and any sub-paths (e.g., /pets/123).
    • Full wildcard: "*::/pets/*" targets all methods on /pets and all sub-paths.

    Note: Always put quotes around the target definition.

    # Example: Target all methods on /pets and its sub-paths
    operations:
      - "*::/pets/*"
  10. Filter by HTTP methods

    main

    Use methods to remove all fields and attached fields that match the specified HTTP verbs. Use inverseMethods to keep only the specified verbs and remove all others.

    # Example: Removing get, put, and post
    methods:
      - get
      - put
      - post
  11. Filter by custom flags and flag values

    main

    Custom properties (flags) can be used to filter the document:

    • flags: Removes all fields matching the specified custom property names (e.g., x-exclude).
    • inverseFlags: An aggressive option that keeps only path operations, tags, and x-tagGroups that match the flags. It keeps components by default.
    • flagValues: Removes fields matching a specific flag name AND value (e.g., x-version: 1.0). This also works for flags containing arrays of values.
    • inverseFlagValues: An aggressive option that keeps only items matching the specified flag/value combination. Like inverseFlags, it keeps components (use unusedComponents to clean those up).
    # Example: Removing specific flag values
    flagValues:
      - x-version: 1.0
      - x-version: 3.0
    
    # Example: Removing a flag entirely
    flags:
      - x-exclude
  12. Understand the openapi-format transformation pipeline

    main

    When running the CLI, transformations are applied in a strict, deterministic sequence. Understanding this order is critical when configuring multiple overlapping features (e.g., filtering before or after casing).

    Pipeline Order:

    1. generate (Operation ID generation)
    2. filter (Removing elements)
    3. overlay (Applying overlay actions)
    4. sort (Ordering fields/components)
    5. casing (Applying casing rules)
    6. convertTo (Version conversion)
    7. rename (Renaming info.title)
    8. Write Output (Writing to file/split or printing to stdout)