fix(typescript-fetch): qualify anyToJSON for any-typed form parameters

[donald]

Fixes #24552

What

A multipart/form-data parameter with no type at all ("any type") made the generated apis/*.ts call
a bare anyToJSON(...). The file only imports the runtime as * as runtime, so that identifier does not
exist and the output does not compile.

import * as runtime from '../runtime';
...
// before -- TS2304: Cannot find name 'anyToJSON'
formParams.append('meta', new Blob([JSON.stringify(anyToJSON(requestParameters['meta']))], { type: "application/json", }));

// after
formParams.append('meta', new Blob([JSON.stringify(runtime.anyToJSON(requestParameters['meta']))], { type: "application/json", }));

Why

apis.mustache#L288:

{{#isFreeFormObject}}runtime.anyToJSON{{/isFreeFormObject}}{{^isFreeFormObject}}{{{dataType}}}ToJSON{{/isFreeFormObject}}

The free-form object case (added with anyToJSON in #1877) is qualified correctly. The any-type case falls
through to {{dataType}}ToJSON, and for an any-typed parameter dataType is any, so it renders as the
unqualified anyToJSON.

How

Add an isAnyType branch that also uses runtime.anyToJSON. Everything else keeps rendering
{{dataType}}ToJSON exactly as before.

Testing

• TypeScriptFetchClientCodegenTest.testAnyTypeFormParamUsesQualifiedAnyToJSON — asserts the generated
  call is namespace-qualified and that the bare form is gone. Verified that this test fails without the
  fix (does not contain line [runtime.anyToJSON(requestParameters['meta'])]).
• Full TypeScriptFetchClientCodegenTest (35 tests) passes.
• Regenerated all 787 sample configs (./bin/generate-samples.sh ./bin/configs/*.yaml) and
  ./bin/utils/export_docs_generators.sh — no diff. No existing sample has an any-typed form
  parameter, which is why this went unnoticed.

Note on the full test run: mvn test on modules/openapi-generator reports one pre-existing failure,
OpenApiSchemaValidationsTest.testNullTypeInOas31_noWarning. It fails identically on unmodified
master (4aed9c1c635) — verified by reverting the patch and re-running — and is unrelated to this change.

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  Commit all changed files.
  (Both scripts were run; neither produced any change, so there is nothing to commit beyond the fix and its test.)
• File the PR against the correct branch: master
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

TypeScript technical committee:
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov @davidgamero @mkusaka @joscha

🤖 Generated with Claude Code

---

Summary by cubic

Qualifies anyToJSON as runtime.anyToJSON for multipart/form-data parameters with no type in typescript-fetch clients. Previously the template emitted a bare anyToJSON(...), causing a compile error; now it uses the runtime-qualified call and other cases still use {{dataType}}ToJSON.

• Changes
  • Update apisFormParams.mustache to use runtime.anyToJSON when isAnyType is true; preserve existing isFreeFormObject and default {{dataType}}ToJSON paths.
  • Add test testAnyTypeFormParamUsesQualifiedAnyToJSON with any-type-form-param.yaml.
  • Regenerate samples; no diffs.

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

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}

[macjohnny]

thx for the fix

[wing328]

@donald can you please resolve the merge conflicts when you've time?

[donald]

@wing328 done — rebased onto master and force-pushed (f774057), the conflicts are gone.

It was a bit more than context drift: master has since extracted the form-param block out of apis.mustache into the new apisFormParams.mustache partial, so I took master's apis.mustache as-is and moved the fix into the partial. That partial is included from two places (apis.mustache and apisContentTypeVariantBody.mustache), so the isAnyType branch now also covers the content-type-split path, not just the plain one.

The second conflict was only both sides appending a test at the same spot — testAnyTypeFormParamUsesQualifiedAnyToJSON now sits next to the new content-type-variant tests.

No sample regeneration needed. The only typescript-fetch sample that reaches that line is samples/client/others/typescript-fetch/additional-properties-in-multipart-issue/apis/FileApi.ts, and its parameter is a declared model (StructuredTypeToJSON), so isAnyType is false there and the rendered output is unchanged. TypeScriptFetchClientCodegenTest is green locally (45 tests, 0 failures).