curl codegen: file-type FormParam contentType ignored — ';type=' not emitted for multipart file parts

[sserrata]

Summary

The curl codegen correctly passes contentType through the preprocessing step for type === 'file' FormParams, but then silently drops it in snippet generation. As a result, -F 'field=@"/path/to/file"' is always emitted without the ;type=<ct> suffix — even when FormParam.contentType is explicitly set.

Steps to reproduce

1. Create a Postman request with a multipart/form-data body.
2. Add a file-type form param (e.g. key attachment, src /path/to/file) and set contentType to image/png on the param.
3. Generate the curl snippet.

Expected:

-F 'attachment=@"/path/to/file";type=image/png'

Actual:

-F 'attachment=@"/path/to/file"'

Root cause

In codegens/curl/lib/index.js, the preprocessing loop (≈ line 107) correctly reads contentType = param.contentType and passes it to addFormParam. However, in snippet generation, contentType is only applied in the else (text-type) branch — never in the data.type === 'file' branch:

if (data.type === 'file') {
  snippet += `...@"${data.src}"...`;
  snippet += quoteType;
  // ← contentType never checked here
}
else {
  // text params
  if (data.contentType) {
    snippet += `;type=${data.contentType}`;  // ← only lands here
  }
  snippet += quoteType;
}

curl fully supports ;type= for file parts:

curl -F 'attachment=@"/path/to/file";type=image/png' https://example.com/upload

Suggested fix

Add the same contentType check inside the data.type === 'file' block, before the closing quote:

if (data.type === 'file') {
  snippet += `...@"${data.src}"`;
  if (data.contentType) {
    snippet += `;type=${data.contentType}`;
  }
  snippet += quoteType;
}

Prior art

PR #418 (merged Nov 2020) introduced ;type= support for text-type form params across several codegens. File-type params were not covered at that time.

Context

Encountered while implementing OAS encoding.contentType support in docusaurus-openapi-docs. When a spec declares per-part content types for multipart/form-data, we set FormParam.contentType accordingly — but the curl snippet never reflects it for binary file fields.