package.json pins "@workos/openapi-spec": "^0.80.0". The latest published version is 0.107.0 — 27 minor versions ahead.
Because the dependency is 0.x, a caret range resolves to >=0.80.0 <0.81.0, so the range never drifts forward on its own. Every bump has to be an explicit edit to package.json.
Renovate does not appear to be opening PRs for it
renovate.json extends github>workos/renovate-config:public, but the bump history suggests the dependency is being carried forward by hand, inside unrelated feature PRs:
| Version |
Landed in |
Date |
^0.6.0 |
#2 — feat: provide an end-to-end login flow story |
2026-06-25 |
^0.41.0 |
#17 — chore(deps): bump @workos/openapi-spec |
2026-07-20 |
^0.59.0 |
(release 0.5.0 window) |
2026-08-04 |
^0.80.0 |
#97 — feat(authorization): align roles and permissions with the spec |
2026-09-03 |
Only #17 looks like a dependency-driven bump. The current pin has been stale for ~3 weeks, and there is no open Renovate PR for it.
The question this issue is asking: is the pin deliberate — a spec version the emulator is known-good against, bumped only when someone does the alignment work — or is it just Renovate not firing? The answer changes whether this is a config fix or a documented policy that should be written down.
What upgrading to 0.107.0 would actually mean
I diffed the two specs. Nothing is removed; 11 endpoints are added (250 → 261):
| Tag |
Endpoints |
Status |
organizations.data-providers |
5 |
new tag |
user-management.authkit-oauth-resources |
3 |
new tag |
pipes |
3 (/data-integrations/{slug}/organization) |
existing tag |
The upgrade breaks bun run gen:supported until FEATURES is updated. Verified by pointing the generator at the 0.107.0 spec:
$ bun run scripts/gen-supported.ts path/to/0.107.0/open-api-spec.yaml --dry-run
error: Spec tags are not assigned to a feature: organizations.data-providers,
user-management.authkit-oauth-resources. Add them to FEATURES in scripts/gen-supported-lib.ts.
at buildMatrix (scripts/gen-supported-lib.ts:563:15)
That guard is deliberate — it exists so a new WorkOS product cannot silently vanish from the table — but it does mean the upgrade cannot land as a bare dependency bump, which may be part of why it keeps riding along inside feature PRs.
Headline coverage would go from 180/250 (72.0%) to 180/261 (69.0%) — no capability lost, just a larger denominator. That is arguably the point: the current figure is flattering because the spec it measures against is three weeks old.
Suggested outcome
- Confirm whether the pin is deliberate. If it is, say so in
SUPPORTED.md or CONTRIBUTING, next to the generated version string.
- If it is not, work out why Renovate is not raising the PR (
0.x caret ranges often need rangeStrategy: bump to move at all) and fix the config.
- Either way, land the 0.107.0 upgrade with
FEATURES entries for the two new tags, so the coverage table reflects the current spec.
Happy to do (3) if the answer to (1) is "not deliberate".
package.jsonpins"@workos/openapi-spec": "^0.80.0". The latest published version is 0.107.0 — 27 minor versions ahead.Because the dependency is
0.x, a caret range resolves to>=0.80.0 <0.81.0, so the range never drifts forward on its own. Every bump has to be an explicit edit topackage.json.Renovate does not appear to be opening PRs for it
renovate.jsonextendsgithub>workos/renovate-config:public, but the bump history suggests the dependency is being carried forward by hand, inside unrelated feature PRs:^0.6.0feat: provide an end-to-end login flow story^0.41.0chore(deps): bump @workos/openapi-spec^0.59.0^0.80.0feat(authorization): align roles and permissions with the specOnly #17 looks like a dependency-driven bump. The current pin has been stale for ~3 weeks, and there is no open Renovate PR for it.
The question this issue is asking: is the pin deliberate — a spec version the emulator is known-good against, bumped only when someone does the alignment work — or is it just Renovate not firing? The answer changes whether this is a config fix or a documented policy that should be written down.
What upgrading to 0.107.0 would actually mean
I diffed the two specs. Nothing is removed; 11 endpoints are added (250 → 261):
organizations.data-providersuser-management.authkit-oauth-resourcespipes/data-integrations/{slug}/organization)The upgrade breaks
bun run gen:supporteduntilFEATURESis updated. Verified by pointing the generator at the 0.107.0 spec:That guard is deliberate — it exists so a new WorkOS product cannot silently vanish from the table — but it does mean the upgrade cannot land as a bare dependency bump, which may be part of why it keeps riding along inside feature PRs.
Headline coverage would go from 180/250 (72.0%) to 180/261 (69.0%) — no capability lost, just a larger denominator. That is arguably the point: the current figure is flattering because the spec it measures against is three weeks old.
Suggested outcome
SUPPORTED.mdorCONTRIBUTING, next to the generated version string.0.xcaret ranges often needrangeStrategy: bumpto move at all) and fix the config.FEATURESentries for the two new tags, so the coverage table reflects the current spec.Happy to do (3) if the answer to (1) is "not deliberate".