Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Prepares the v0.19.0 release of the library and introduces a new CLI flag intended to control “query-safe” (readonly-required) response typing for GET operations during code generation.
Changes:
- Add
--use-query-safe-response/--no-use-query-safe-responseoption parsing, help text, and plumbing intoapi-types.tsgeneration. - Bump package version to
0.19.0and update README npm badge. - Add a
0.19.0entry to the changelog.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/cli.ts | Adds the new CLI flag, updates usage text, and passes the flag into generateApiTypesContent. |
| package.json | Version bump to 0.19.0. |
| package-lock.json | Lockfile version metadata updated to 0.19.0. |
| README.md | Updates npm badge cache-busting version parameter to 0.19.0. |
| CHANGELOG.md | Adds the 0.19.0 release entry documenting the new flag. |
dd7ad86 to
145d65b
Compare
- Remove --no-exclude flag, use --exclude-prefix false instead - Add --use-query-safe-response flag (default: true) to automatically return ApiResponseSafe for useQuery - All fields required for GET responses (assumes API shares schema for POST/PATCH and GET) - Add searchPets operation to toy-openapi.json for consistent test generation - Update tests to include new searchPets operation Changes: - CLI: --exclude-prefix 'false' disables exclusion (instead of --no-exclude) - CLI: --use-query-safe-response enables ApiResponseSafe for queries (default) - CLI: --no-use-query-safe-response disables for cases where readonly fields aren't distinguished - Updated help text with documentation on semantic distinction - Regenerated test fixtures with searchPets and default ApiResponseSafe
145d65b to
edc0370
Compare
Use --use-query-safe-response false instead to disable
Updated type semantics based on requirements: - ApiResponseSafe (GET/useQuery): Now requires ALL fields including optional * Assumes API shares schema for POST/PATCH and GET * Server always returns all fields for GET operations - ApiResponse (POST/PATCH/useMutation): Excludes readonly, preserves optional * Readonly fields excluded (client cannot set them) * Optional fields observed as per OpenAPI spec Changes: - Renamed RequireReadonly to ExcludeReadonly (now excludes readonly fields) - ApiResponse now uses ExcludeReadonly instead of RequireAll - ApiResponseSafe now uses RequireAll (makes ALL fields required) - Updated all documentation and help text to reflect correct semantics - Updated README examples - Regenerated test fixtures with updated comments This is a breaking change as ApiResponseSafe now requires optional fields that were previously optional.
Major semantic fix based on correct requirements: 1. ALL responses (GET, POST, PUT, PATCH, DELETE) now use the SAME type 2. By DEFAULT, ApiResponse makes ALL fields required (assumes server always returns everything) 3. NEW --use-strict-response flag for ApiResponseStrict (only readonly/required fields required) 4. Readonly ONLY affects request bodies (mutations), NOT response types Type Changes: - ApiResponse (default): ALL fields required for ALL responses - ApiResponseStrict (opt-in): Only readonly OR required fields are required - Removed ApiResponseSafe (was conceptually wrong) - Added RequireReadonlyOrRequired helper type CLI Changes: - Removed --use-query-safe-response flag - Added --use-strict-response flag (defaults to false) - Updated all help text and log messages - Response type is now consistent across ALL operations (no query vs mutation distinction) Breaking Changes: - ApiResponseSafe removed (use ApiResponse or ApiResponseStrict) - All responses now default to ALL fields required - --use-query-safe-response flag removed This aligns with the correct semantic: readonly affects what you can POST, not what the API returns.
Updated: - CHANGELOG.md: Added Unreleased section documenting breaking changes - CHANGELOG.md: Updated v0.13.0 entry with note about incorrect semantics - tests/unit/readonly-properties.test.ts: Updated to use ApiResponseStrict - Test descriptions now reflect correct semantics: * ApiResponse (default): ALL fields required * ApiResponseStrict (opt-in): Only readonly/required fields required * readonly only affects request bodies, not responses All 342 tests passing with updated semantics.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 15 out of 15 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
src/cli.ts:1404
- When
useStrictResponseis enabled, the generated api-client import list still includesApiResponseeven though all generatedResponsealiases useApiResponseStrict. In consumer projects withnoUnusedLocals/lint rules enabled, this can make the generated file fail to compile. Consider emitting only the selected response type in the import (eitherApiResponseorApiResponseStrict) based onuseStrictResponse.
import type {
ApiResponse${useStrictResponse ? ',\n ApiResponseStrict' : ''},
ApiRequest,
ApiPathParams,
ApiPathParamsInput,
ApiQueryParams,
operations,
} from './api-operations.js'
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Release v0.19.0 with improved response type semantics and optimized import handling.
Changes
Added
--use-strict-responseCLI flag to control whether all fields are requiredApiResponse(ALL fields required, matches typical API behavior)ApiResponseStrict(only readonly/required fields required)Fixed
ApiResponseorApiResponseStrict) instead of always importing both, preventingnoUnusedLocalslint errors in strict TypeScript projectsChanged
ApiResponseSafetype (useApiResponseStrictinstead)--use-query-safe-responseflag (replaced with--use-strict-response)Related Issues
Testing
npm run lint,npm run types,npm run test:run