Allow pageParam to be a string within generated infiniteQueries

[robert-pitt-foodhub]

Describe the bug
Our API uses string as page parameters, such as base64 encoded global ids, however when generating infinite queries where the type of pageParam is not a number within the schema

To Reproduce

1. Generate schemas where the page types are strings using openapi-rq --pageParam nextPageKey --nextPageParam nextPageKey -i specification.json -c axios
2. See the generated queries/infiniteQueries.ts file for type error

OpenAPI spec file
Would like to keep private

Expected behavior
If the schema defines the page token as a string then the generated types should also require a string.

Screenshots

Type Error:

Schema:

• OS: macOS
• Version 1.6.0

Additional context
N/A

[7nohe]

Fixed in v3.0.0.

The generator now resolves the page parameter's type from the schema — including through type aliases — and emits a matching type in all three positions instead of hardcoding number. For a spec where the cursor is Cursor: { type: string }:

queryFn: ({ pageParam, signal }) => listItems({ ...clientOptions, query: { ...clientOptions.query, page: pageParam as Cursor }, ... })
initialPageParam: "1",
getNextPageParam: (response: unknown) => (response as { nextPage: Cursor }).nextPage,

No as number on the string path, and initialPageParam is quoted so it stays a string.

Two things worth knowing for a cursor-based API, since a default of "1" is rarely meaningful as a cursor:

• --initialPageParam "" emits initialPageParam: ""
• --omitInitialPageParam (added in v3) omits the page parameter from the first request entirely, which is usually what a cursor API wants — the server returns the first page when no cursor is supplied

Available on latest (npm i @7nohe/openapi-react-query-codegen@3). Thanks for the report, and sorry it took a while.