chore: point apify-client at the OpenAPI-generated models branch [WIP] - #702
Draft
vdusek wants to merge 1 commit into
Draft
chore: point apify-client at the OpenAPI-generated models branch [WIP]#702vdusek wants to merge 1 commit into
vdusek wants to merge 1 commit into
Conversation
|
See more at https://github.com/apify/apify-sdk-js/actions/runs/32944382474#summary-98101870613 |
vdusek
changed the title
vdusek
added a commit
to apify/apify-client-js
that referenced
this pull request
Aug 27, 2026
## Description - API response types are now generated from the OpenAPI specification instead of hand-written, using [openapi-typescript](https://openapi-ts.dev/). - `pnpm generate:types` downloads the specification into git-ignored `tmp/` and writes `src/generated/api.ts`. Only the specification version is committed, in `package.json`. - Nothing re-exports the generated file: `src/models.ts` declares each published model on top of a generated schema, and `src/spec_guards.ts` asserts every deviation at compile time. - A nightly CI workflow regenerates and opens a pull request if anything changed. - It follows the same approach as the Python API client. ## Breaking - Several types were outright wrong, and many fields gained null or became optional to match what the API actually returns. - Two runtime changes: `parseDateFields()` depth 3 -> 4, and the key-value store's next-key check widens to `!= null`. - Everything is described in the v3 upgrading guide. ## Downstream - apify/apify-sdk-js#702 runs the v4 SDK against this branch: six type errors, all absorbed by v4's backend adapters. Build, typecheck, unit tests, lint and format pass. - `handledAt` and `retryCount` break only on the v3 line, where the SDK relies on structural `StorageClient` compatibility. ## Open - `notify_on_failure` needs a `SLACK_WEBHOOK_URL` secret this repo does not have. *✍️ Drafted by Claude Code*
vdusek
added a commit
to apify/apify-client-js
that referenced
this pull request
Sep 8, 2026
- API response types are now generated from the OpenAPI specification instead of hand-written, using [openapi-typescript](https://openapi-ts.dev/). - `pnpm generate:types` downloads the specification into git-ignored `tmp/` and writes `src/generated/api.ts`. Only the specification version is committed, in `package.json`. - Nothing re-exports the generated file: `src/models.ts` declares each published model on top of a generated schema, and `src/spec_guards.ts` asserts every deviation at compile time. - A nightly CI workflow regenerates and opens a pull request if anything changed. - It follows the same approach as the Python API client. - Several types were outright wrong, and many fields gained null or became optional to match what the API actually returns. - Two runtime changes: `parseDateFields()` depth 3 -> 4, and the key-value store's next-key check widens to `!= null`. - Everything is described in the v3 upgrading guide. - apify/apify-sdk-js#702 runs the v4 SDK against this branch: six type errors, all absorbed by v4's backend adapters. Build, typecheck, unit tests, lint and format pass. - `handledAt` and `retryCount` break only on the v3 line, where the SDK relies on structural `StorageClient` compatibility. - `notify_on_failure` needs a `SLACK_WEBHOOK_URL` secret this repo does not have. *✍️ Drafted by Claude Code*
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
2 participants
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.
Experiment, not for merge. Points
apify-clientat the branch of apify/apify-client-js#985 (all output models generated from the OpenAPI spec) to see what the change does to the v4 SDK.How the dependency is referenced
"apify-client": "github:apify/apify-client-js#feat/openapi-generated-models", the npm equivalent ofpip install git+.... Two things make it work:preparescript, so a git checkout builds its owndist/. Without it the install lands with nodist/whilemain/typespoint into it.apify-clientis added toonlyBuiltDependencies, since pnpm refuses build scripts for git-hosted packages otherwise.What broke, and why
Six type errors, from two changes in the generated models:
nameand the key-value store'sexclusiveStartKey/nextExclusiveStartKeygainnullpricingPerEvent.actorChargeEventsandActorChargeEvent.eventPriceUsdbecome optionalThe first group is normalised where the client meets Crawlee, in the backend adapters: the API spells absence as
null, Crawlee spells itundefined. The second is handled inChargingManager; an absent per-event price counts as no charge, which is worth a second opinion.Notably
handledAtandretryCountdo not break here. On the v3/master line they do, because the SDK relies onApifyClientstructurally satisfying Crawlee'sStorageClient; v4's explicit backend adapters map those fields instead.Status
tsc(src and tests), build, unit tests, oxlint and oxfmt all pass. Platform e2e is dispatch-only, so it has to be triggered by hand on this branch.✍️ Drafted by Claude Code