fix: pin @sourceacademy/conductor to ^0.8.0 across all plugin packages - #82
Conversation
Every runner/web plugin package declared its conductor dependency as the loose range ">=0.3.0" (peerDependencies and devDependencies alike). Yarn's resolver satisfies the loosest range with the oldest compatible version already in the graph, so this silently deduped to conductor 0.3.0 across the whole workspace - five minor releases behind the actual 0.8.x protocol, despite the root package.json and CI both targeting ^0.8.0. A locally-built plugin bundle under this stale resolution is protocol- incompatible with any host/runner built against current conductor (e.g. frontend via portal-link, or production evaluator bundles), surfacing as opaque runtime RPC errors rather than a build-time failure. Tightens all 13 occurrences to ^0.8.0, matching the convention already used by the root package.json and runner-module-loader's own peerDependency.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (13)
WalkthroughThe pull request updates ChangesConductor dependency alignment
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Summary
Every runner/web plugin package (13
package.jsonfiles) declared its@sourceacademy/conductordependency using the loose range">=0.3.0", in bothpeerDependenciesanddevDependencies. Yarn's resolver satisfies the loosest requested range with the oldest already-resolved version it can find, so this silently deduped conductor to0.3.0across the entire workspace — five minor releases behind the actual0.8.xprotocol, despite the rootpackage.json(andrunner-module-loader's own peer dependency) already correctly targeting^0.8.0.Why this matters
A plugin bundle built under this stale resolution is protocol-incompatible with any host/runner built against current conductor — e.g.
frontendconsuming it via a portal link in local dev, or a production evaluator bundle built against a recent conductor release. The failure mode is not a build error (everything type-checks and bundles fine against 0.3.0's shape) — it surfaces at runtime as an opaque host↔runner RPC error once the two sides actually try to talk to each other, which is a much harder failure to trace back to a dependency version.Discovered while debugging a local
dev.sh-based dev environment fordata-visualizer: the freshly-built plugin bundle was silently linking against conductor 0.3.0 while the host and runner it needed to talk to were on 0.8.2, producing aTypeError: o[r] is not a functiondeep in the MessagePort RPC layer with no indication of a version mismatch.Fix
Tightens all 13 occurrences (in
src/web/*andsrc/runner/*, bothpeerDependenciesanddevDependencieswhere present) to^0.8.0, matching the convention already used by the rootpackage.json.yarn.locknow resolves@sourceacademy/conductorto a single0.8.1entry workspace-wide (the newest version satisfying^0.8.0currently in the lockfile's fetch cache) instead of splitting between0.3.0and0.8.x.Note:
yarn.lockstill carries one unrelated@sourceacademy/conductor@npm:^0.3.0entry — that belongs torunner-remoteExecution/runner-test's pinnedpy-slangfork dependency (github:proto-aiken-13/py-slang#branch-ev3-engine), which declares its own conductor dependency independently. That's outside this repo's control and isolated by Yarn's PnP resolution from the packages fixed here, so it's left untouched.Verification
yarn install— conductor resolves to0.8.1everywhere referenced by this repo's own packages (confirmed viayarn.lock).yarn build— clean build across all packages.yarn test— 139/139 passing (4 unrelated failures come from a stale, pre-existing worktree under.claude/worktrees/that vitest happens to glob into; unrelated to this change, reproduced independently of it).web/stepper/src/SubstVisualizer.tsx(an unrelatedStepperNodetype mismatch) is present identically on unmodifiedmain— not introduced by this change.