v1.5.2

• chore: replace js-yaml dependency with yaml

v1.5.1

• fix: correctly escape prop names in deep object properties
• chore: upgrade deps

v1.5.0

This is a minor bump because of dependencies upgrade. For example new commander bumped minimum node version to v20. It does not mean the Swaggie stopped working for node < 20, but it's not officially supported.
In the Github Actions I check if swaggie actually executes for node 18, 20, 22 and 24.

• chore: Upgrade dependencies and remove undici as a direct dependency
• chore: Replace internally yarn with bun
• chore: Replace node test runner with bun test runner which makes setup for running tests much easier and tests are running faster
• impr: Get rid of direct undici dependency as fetch is supported natively in all supported node versions

v1.4.2

• impr: better support for referenced parameters
• fix: Include descriptions for params in the JSDocs for operation

v1.4.1

• fix: broken templates when no JSDocs were available for an operation (these pesky EJS templates 😅 )

v1.4.0

• fix: escape operation's parameter names that could conflict with internally used variable names
• impr: Better handle JSDocs comments in all templates
• impr: Replace known HTML tags with Markdown equivalents and then encode rest of them to valid HTML entities. This way previewing JSDocs in VSCode, Cursor, etc will be much more useful
• fix: Prevent duplication in JSDocs if Summary is also part of the Description fields.

v1.3.1

• fix: properly detect when JSDocs comments should be rendered for operations

v1.3.0

• feat: Added skipDeprecated option to exclude deprecated operations from generation (disabled by default)
• feat: Smart component schema filtering - automatically detects and skips unused component schemas (only when skipDeprecated is enabled)
• fix: Enhanced sanitization for path parameters, component names, property names, and enum values to ensure valid TypeScript identifiers. A lot of lessons learned from testing large, poorly-structured OpenAPI specifications
• impr: Expanded reserved keywords list for better TypeScript compatibility
• impr: Better OpenAPI 3.1 support for anyOf/oneOf nullable types
• impr: Enhanced documentation generation - comments now include description or title fields from spec
• chore: improved test coverage, internal comments and overall code quality

Before and after this version: (sanitization)

-export interface CategoryNodeBase-Output {
-  X-Amz-Algorithm: string;
-  67de71395bbe4: string;
-  created at?: string;
-  updated-at?: string;
-}
+export interface CategoryNodeBase_Output {
+  "X-Amz-Algorithm": string;
+  "67de71395bbe4": string;
+  "created at"?: string;
+  "updated-at"?: string;
+}

v1.2.1

• fix: detect YAML files in a more reliable way. Before, the extension was determining the type, but sometimes the spec can be hosted as a resource without the extension. In such cases we will check the contents to determine if this JSON or YAML file.

v1.2.0

• feat: Added global parameter modifiers. More explanation below
• impr: Introduced skippable parameters - if optional parameters is not followed by required one, it will be rendered as p1?: string | null so it's possible to skip such parameters when calling operation
• refactor: Replaced mocha + chai with node test runner + tsx
• chore: upgrade deps
• fix: matrix testing of node versions in Github Actions is now fixed

Parameter modifiers

This feature addresses scenarios where OpenAPI specifications contain globally-defined parameters that are already handled by application interceptors, eliminating redundant parameter definitions.

When working with REST APIs that define interceptors for common functionality (such as authentication), the OpenAPI specification may explicitly include these parameters across all operations. While Swaggie correctly interprets these as required parameters, your application's interceptor may already provide this information automatically, making manual parameter specification redundant.

Parameter modifiers can be configured through the config.json file using the following structure:

{
  "modifiers": {
    "parameters": {
      "param1": "optional",
      "param2": "ignore"
    }
  }
}

Available Modifiers:

ignore - Removes the parameter from all operations and paths entirely (most common use case)
optional - Makes a parameter optional while preserving interceptor functionality
required - Forces a parameter to be marked as required, useful when the OpenAPI spec doesn't properly define a parameter's necessity

Note: When using the optional modifier, the interceptor's default value takes precedence in the outgoing request. Ensure your interceptor logic can handle cases where the parameter might be explicitly provided.

For the parameter's name you want to to modify you can provide either the original name from the spec, or the name as visible in the generated code.