[typescript-fetch] Add option to exclude RequestOpts from API interfaces

[guizmaii]

Summary

• Add a new withRequestOptsInInterface boolean option (default: true for backward compatibility) to the TypeScript Fetch client generator
• When set to false, the *RequestOpts methods are excluded from the generated API interface declarations while remaining as public methods on the API class
• The *RequestOpts methods are implementation details that build request options before the fetch call -- most consumers using the API interfaces don't need them in the contract

Changes

TypeScriptFetchClientCodegen.java: Added WITH_REQUEST_OPTS_IN_INTERFACE constant, field, getter/setter, CLI option registration, and processing in processOpts()

apis.mustache: Wrapped the *RequestOpts method declaration in the interface block with a {{#withRequestOptsInInterface}} conditional

TypeScriptFetchClientCodegenTest.java: Added two tests:

• testRequestOptsInInterfaceByDefault: verifies the default behavior (RequestOpts in both interface and class)
• testRequestOptsNotInInterfaceWhenDisabled: verifies that with withRequestOptsInInterface=false, RequestOpts methods appear only on the class, not in the interface

Usage

# In your OpenAPI Generator config
additionalProperties:
  withInterfaces: true
  withRequestOptsInInterface: false  # Exclude *RequestOpts from interfaces

Test plan

• Existing tests pass (24/24)
• New test: testRequestOptsInInterfaceByDefault -- verifies default behavior preserves backward compatibility
• New test: testRequestOptsNotInInterfaceWhenDisabled -- verifies RequestOpts exclusion from interface while keeping them on the class

---

Summary by cubic

Adds an option to hide *RequestOpts methods from generated typescript-fetch API interfaces, keeping them only on the class. Default behavior stays the same to preserve backward compatibility.

• New Features

  • Added withRequestOptsInInterface (default: true) to control whether *RequestOpts appear in API interfaces.
  • When false, *RequestOpts are excluded from interfaces but remain public on the API class.
  • Updated generator, template, and docs; tests cover both modes (including options provider) with interface-scoped assertions. Use with additionalProperties: { withInterfaces: true, withRequestOptsInInterface: false }.

• Bug Fixes

  • Scoped RequestOpts test assertions to the interface section to avoid false positives.
  • Fixed forbiddenapis violation by reading files with StandardCharsets.UTF_8.

^{Written for commit f4afe8e. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/test/java/org/openapitools/codegen/typescript/fetch/TypeScriptFetchClientCodegenTest.java">

<violation number="1" location="modules/openapi-generator/src/test/java/org/openapitools/codegen/typescript/fetch/TypeScriptFetchClientCodegenTest.java:473">
P2: `testRequestOptsInInterfaceByDefault` can pass even when RequestOpts is missing from interface due to un-scoped file search</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

No issues found across 3 files

[guizmaii]

The ci/circleci: node2 failure is unrelated to this PR -- it's an infrastructure issue in the cpp-restsdk CI environment (apt package installation of clang/llvm/boost dependencies fails with exit code 1 during setup, before any tests run).

The same check is also failing on master.

All checks relevant to the typescript-fetch changes are passing.

[wing328]

agreed circleci failure not related to this change, which looks good to me

thanks for the contribution

[wing328]

cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02) @davidgamero (2022/03) @mkusaka (2022/04) @joscha (2024/10) @dennisameling (2026/02)