fix: serialize format: date query params as YYYY-MM-DD

[rolego]

Summary

• When dates: true is enabled in @hey-api/transformers, query parameters with format: date are typed as Date. Previously, Date objects were serialized via .toISOString() producing full timestamps like 2025-12-17T00:00:00.000Z instead of the RFC 3339 full-date 2025-12-17.
• Adds a date option to QuerySerializerOptions and emits per-parameter date format hints ({ date: 'date' } or { date: 'date-time' }) in the SDK codegen.
• All 7 client bundles (angular, axios, fetch, ky, next, nuxt, ofetch) now check instanceof Date before serializing query params, using .toISOString().slice(0, 10) for format: date and full .toISOString() for format: date-time.

Test plan

• Added test spec specs/3.1.x/transformers-date-query-params.json with both date and date-time query params
• Added snapshot test in 3.1.x.test.ts — verifies generated SDK emits querySerializer: { parameters: { stichdatum: { date: 'date' }, timestamp: { date: 'date-time' } } }
• Updated ~500 snapshot files to reflect new instanceof Date check in generated client code
• pnpm build, pnpm typecheck, and pnpm lint pass
• Verified in a real Angular project that stichdatum=2025-12-17 is sent instead of stichdatum=2025-12-17T00:00:00.000Z

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[pullfrog]

Reviewed PR #3723. The approach is sound — instanceof Date checks are correctly placed in all 7 client bundles, and the codegen properly emits per-parameter date hints. Main feedback: the date hint emission in operation.ts is unconditional (runs even without @hey-api/transformers), producing dead config in non-transformer setups. Suggested gating it on the transformer plugin, and recommended adding runtime unit tests for the new Date serialization path.

Task list (6/6 completed)

• Read the diff to identify major areas of change
• Review core logic changes (query serialization, client bundles)
• Review codegen changes (SDK parameter hints)
• Review test spec and snapshots
• Impact analysis and self-critique
• Submit review

  ^{｜ View workflow run ｜ Triggered by Pullfrog ｜ 𝕏}

[changeset-bot]

🦋 Changeset detected

Latest commit: 383f420

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@hey-api/openapi-ts	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@rolego is attempting to deploy a commit to the Hey API Team on Vercel.

A member of the Team first needs to authorize it.

[pullfrog]

TL;DR — Query parameters declared with format: "date" were being serialized as full ISO datetime strings (e.g. 2025-04-07T00:00:00.000Z). This PR fixes the runtime serializer and code generator so Date values on format: date params are emitted as YYYY-MM-DD — but only when @hey-api/transformers with dates: true is active, since that's the only scenario where query params become Date objects.

Key changes

• Add Date instance handling to createQuerySerializer in all client bundles — A new branch intercepts Date values before array/object checks and formats them as YYYY-MM-DD when the parameter's date option is 'date', or full ISO otherwise.
• Extend QuerySerializerOptionsObject with a date property — Adds date?: 'date' | 'date-time' so per-parameter serialization config can specify the desired date format.
• Emit per-parameter querySerializer config in generated SDKs, gated on transformers plugin — The code generator inspects each query parameter's schema for type: string + format: date/date-time and emits serializer hints, but only when @hey-api/transformers is configured with dates enabled.
• Add unit tests for createQuerySerializer Date serialization across all seven client plugins — Three test cases per client (fetch, angular, axios, ky, next, nuxt, ofetch) verify default ISO output, YYYY-MM-DD with date: 'date', and full ISO with date: 'date-time'.
• Add test spec and snapshot for format: date query params — New OpenAPI 3.1 spec (transformers-date-query-params.json) with both date and date-time query params, plus a corresponding test case and full snapshot output.
• Add changeset for release tracking — Patch changeset for @hey-api/openapi-ts describing the format: date query param serialization fix.
• Regenerate example client code and ~560 snapshot files — All existing utils.gen.ts and bodySerializer.gen.ts snapshots updated to reflect the new serializer logic across examples, SDKs, Valibot, and Zod test fixtures.

_{Summary ｜ 583 files ｜ 10 commits ｜ base: main ← fix/date-query-param-serialization}

Runtime Date serialization in query strings

Before: Date objects in query parameters fell through to the generic object serializer, producing full ISO timestamps like 2025-04-07T00:00:00.000Z — even for format: date params that should only carry the date portion.
After: createQuerySerializer now explicitly checks value instanceof Date and reads an options.date flag to decide the output format — 'date' produces YYYY-MM-DD via toISOString().slice(0, 10), while 'date-time' (or unset) produces the full ISO string.

The same logic is added to all seven client bundles (fetch, axios, angular, ky, next, nuxt, ofetch) so the fix applies regardless of which HTTP client the consumer uses. Each client now has its own set of three unit tests verifying the serialization behavior: default ISO output, YYYY-MM-DD when date: 'date' is set, and full ISO when date: 'date-time' is set.

packages/openapi-ts/src/plugins/@hey-api/client-fetch/bundle/utils.ts · packages/openapi-ts/src/plugins/@hey-api/client-core/bundle/bodySerializer.ts · packages/openapi-ts/src/plugins/@hey-api/client-fetch/__tests__/utils.test.ts · packages/openapi-ts/src/plugins/@hey-api/client-angular/__tests__/utils.test.ts

Code generation emits date serializer hints only when transformers are active

Before: The SDK code generator emitted querySerializer date hints for any query param with format: date/date-time, regardless of whether the transformers plugin was enabled.
After: The generator now checks plugin.getPlugin('@hey-api/transformers')?.config.dates before emitting per-parameter date format hints, ensuring the metadata is only generated when date transforms are actually in use.

This refinement prevents unnecessary querySerializer config from appearing in generated SDKs that don't use @hey-api/transformers — where query params remain plain strings and never become Date objects.

How does the per-parameter config flow from spec to runtime?

At code generation time, operation.ts inspects each query parameter's schema. When it finds type: 'string' with format: 'date' or 'date-time' and the transformers plugin has dates enabled, it emits a querySerializer.parameters entry — e.g. { stichdatum: { date: 'date' } }. At runtime, createQuerySerializer reads this config and applies the correct Date formatting before passing the value to serializePrimitiveParam.

packages/openapi-ts/src/plugins/@hey-api/sdk/shared/operation.ts · specs/3.1.x/transformers-date-query-params.json · packages/openapi-ts-tests/main/test/3.1.x.test.ts · .changeset/serialize-date-query-params.md

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

[pullfrog]

Important

The codegen emits querySerializer date hints unconditionally — even when @hey-api/transformers is not enabled (and the param type is string, not Date). This is harmless at runtime but adds dead config to every generated SDK that has format: date query params without transformers. Consider gating the hint emission on the transformer plugin being active, consistent with how responseTransformer is already gated at line 350.

No runtime tests exist for the new instanceof Date branch — only snapshot coverage for the generated code. A unit test for createQuerySerializer with a Date value and { date: 'date' } option would be valuable.

The overall approach is sound: placing instanceof Date before Array.isArray() is correct (since Date passes typeof value === 'object' and would otherwise be serialized as [object Object]), the date type option is cleanly scoped, and all 7 client bundles are updated consistently. The new else if branch in operation.ts follows the existing pattern for array/object serializers.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ 𝕏}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 39.90%. Comparing base (838c39b) to head (383f420).
⚠️ Report is 37 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3723      +/-   ##
==========================================
- Coverage   40.07%   39.90%   -0.17%     
==========================================
  Files         522      530       +8     
  Lines       19311    19507     +196     
  Branches     5766     5832      +66     
==========================================
+ Hits         7738     7784      +46     
- Misses       9371     9489     +118     
- Partials     2202     2234      +32     

Flag	Coverage Δ
unittests	39.90% <ø> (-0.17%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pkg-pr-new]

Open in StackBlitz

@hey-api/codegen-core

npm i https://pkg.pr.new/@hey-api/codegen-core@3723

@hey-api/json-schema-ref-parser

npm i https://pkg.pr.new/@hey-api/json-schema-ref-parser@3723

@hey-api/nuxt

npm i https://pkg.pr.new/@hey-api/nuxt@3723

@hey-api/openapi-ts

npm i https://pkg.pr.new/@hey-api/openapi-ts@3723

@hey-api/shared

npm i https://pkg.pr.new/@hey-api/shared@3723

@hey-api/spec-types

npm i https://pkg.pr.new/@hey-api/spec-types@3723

@hey-api/types

npm i https://pkg.pr.new/@hey-api/types@3723

@hey-api/vite-plugin

npm i https://pkg.pr.new/@hey-api/vite-plugin@3723

commit: 383f420

[rolego]

Dear @mrlubos
Please let me know if there is anything missing on this PR. It would be nice if this fix could be merged and released soon.
Thanks.