feat(sdk): widen @relayfile/sdk dep range (unblocks cloud 0.3.x)#763
feat(sdk): widen @relayfile/sdk dep range (unblocks cloud 0.3.x)#763khaliqgant merged 1 commit intomainfrom
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b77b97603
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "packages/acp-bridge/node_modules/@agent-relay/sdk": { | ||
| "version": "4.0.34", | ||
| "resolved": "https://registry.npmjs.org/@agent-relay/sdk/-/sdk-4.0.34.tgz", | ||
| "integrity": "sha512-D3vwxkxZtgqqPUAi42ZZL7NxnQtz8qz3p0/7RDgy31hFaKNW6k0Wlp/9xhvoiGhv722mR4KhOvsMIumyOzPonw==", |
There was a problem hiding this comment.
Align workspace SDK pins with 4.0.35
This commit bumps the local workspace package to @agent-relay/sdk@4.0.35, but lockfile now resolves a registry copy of @agent-relay/sdk@4.0.34 for workspace consumers (shown here under packages/acp-bridge/node_modules). That fallback copy still carries the old @relayfile/sdk constraint, so dependent workspace builds/tests won’t run against the updated SDK and can continue to reproduce the duplicate-type behavior this change is meant to eliminate. Internal package pins should be updated (or moved to workspace ranges) so these consumers resolve the local 4.0.35 package.
Useful? React with 👍 / 👎.
Context: - @agent-relay/sdk pinned @relayfile/sdk at ^0.1.2 as a regular dep. - Consumers (AgentWorkforce/cloud) bumped @relayfile/sdk to ^0.3.0 for contentIdentity support in workspace packages (core, web, relayfile, specialist-worker). - The ^0.1.2 caret range can't dedupe against a ^0.3.0 caret range, so npm installed two copies (0.1.13 at root, 0.3.0 nested), producing "duplicate RelayFileClient type" errors during tsc in cloud. Fix: - Switch @relayfile/sdk from `^0.1.2` to `>=0.1.2 <1` in packages/sdk (the @agent-relay/sdk package's) dependencies. npm can now pick any 0.x version that satisfies both this SDK and the consumer, typically deduping to whatever the consumer already uses. - No version bump here — the chore(release) workflow bumps all workspace packages atomically (per Devin feedback: bumping sdk alone to 4.0.35 while other workspace consumers still pin 4.0.34 breaks local workspace linking, falling back to the registry copy). - No runtime behavior change — this package only imports `RelayFileClient` (from provisioner/seeder.ts), whose interface is stable from 0.1.x through 0.3.x. Unblocks: AgentWorkforce/cloud#231 — removes the need for a root `overrides: @relayfile/sdk` workaround in that repo once the next release ships. Verified: - `npm install` resolves clean, workspace consumers link locally. - `npm run build -w @agent-relay/sdk` passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5b77b97 to
6b25da3
Compare
|
Addressed Devin + Codex feedback in force-push 6b25da3: Reverted the premature version bump (kept at 4.0.34) per Option 1 in Devin's suggestion. Workspace consumers pin Diff is 1 file meaningful change: Build + install verified:
|
Summary
`@agent-relay/sdk` pins `@relayfile/sdk` at `^0.1.2`. Downstream cloud workspace packages (`@cloud/core`, `@cloud/web`, `@cloud/relayfile`, `@cloud/specialist-worker`) bumped to `^0.3.0` to pick up the `contentIdentity` field on write ops. The two caret ranges can't dedupe, so npm installs two copies of `@relayfile/sdk` (0.1.x at top level, 0.3.x nested), producing duplicate `RelayFileClient` type identity errors during `tsc` in cloud.
Change
Widen `@relayfile/sdk` in `packages/sdk/package.json` from `^0.1.2` to `>=0.1.2 <1`. No runtime change — this package only imports `RelayFileClient` (provisioner/seeder.ts), whose interface is stable 0.1.x through 0.3.x. Patch bump 4.0.34 → 4.0.35.
Why a range, not a peer dep
`@agent-relay/sdk` is widely consumed as a regular dep. Converting to peer would force every consumer to install `@relayfile/sdk` explicitly — a breaking distribution change. Range-widening in `dependencies` is backward-compatible: existing consumers keep getting a working install (latest 0.1.x if nothing else constrains it); consumers with their own 0.3.x pin dedupe against that instead of pulling a second nested copy.
Unblocks
Test plan
Followup (not this PR)
If peer-style distribution is desired long-term, that's a separate 5.x change: remove `@relayfile/sdk` from `dependencies`, add as `peerDependencies`, doc the breaking change in the changelog, consumers update their package.json. Out of scope here.