feat(runner): provide shared local flow runtime deps#1374
Conversation
WalkthroughThis PR adds shared Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Re-apply flowRuntimeDeps/getInbox wiring onto main's runStagedFlows + buildFlowsRunDeps architecture (main refactored the inline run path away).
- await async createFlowRuntimeDeps in flowRuntimeDeps tests - add createFlowRuntimeDeps to runStagedFlows mock fixture - restore dropped describe brace in runAndroidFlow tests - update envVarDeps test to main's quote/round-trip dotenv contract - use type-only import for createFlowRuntimeDeps in runStagedFlows (lint)
|
Tested against node and binary versions only one addition needed is that some flows will call |
Resolve buildFlowsRunDeps/runStagedFlows conflicts by threading both flowRuntimeDeps (ours) and main's projectDir into the runner deps bundle.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/commands/flows/runStagedFlows.ts (1)
75-77: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
envDirshould point at the project.envdirectory here, notruntimeEnv.depsRoot.makeEnvVarDepsuses this value as the.envtarget, so the current wiring writes env changes into the managed cache instead of the project/--envdirectory and breaks the persistence round-trip. PassenvDir ?? projectDir ?? process.cwd()instead.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/commands/flows/runStagedFlows.ts` around lines 75 - 77, Update the environment-directory argument used by makeEnvVarDeps in the runStagedFlows flow so it receives envDir ?? projectDir ?? process.cwd(), rather than runtimeEnv.depsRoot. Keep loadEnvFile aligned with this same project/--env directory selection to preserve environment changes in the intended location.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/commands/flows/runDefaults.handle.test.ts`:
- Around line 27-30: Replace the loosely typed createFlowRuntimeDepsMock
declarations in runDefaults.handle.test.ts and hybridRun.test.ts with
mock<StagedRunDeps["createFlowRuntimeDeps"]>(), and remove the corresponding
unknown-based double casts when assigning them to createFlowRuntimeDeps. Apply
this to both occurrences in hybridRun.test.ts so the mocks enforce the real
function signature.
In `@src/domains/emails/configureEmails.ts`:
- Around line 58-65: Update registerLazyEmailsClient to configure the SDK with a
complete EmailsClient rather than only { getInbox }; preserve lazy behavior by
supplying valid implementations for all required client methods, or introduce
and call a dedicated lazy-specific setter in the SDK. Ensure the configured
client supports mail.inbox() and satisfies the configureEmailsClient type
contract.
---
Outside diff comments:
In `@src/commands/flows/runStagedFlows.ts`:
- Around line 75-77: Update the environment-directory argument used by
makeEnvVarDeps in the runStagedFlows flow so it receives envDir ?? projectDir ??
process.cwd(), rather than runtimeEnv.depsRoot. Keep loadEnvFile aligned with
this same project/--env directory selection to preserve environment changes in
the intended location.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 7cdb3e3e-9d77-4b89-95c5-702f71c6afdb
📒 Files selected for processing (21)
.changeset/shared-flow-runtime-deps.mdsrc/commands/flows/buildFlowsRunDeps.tssrc/commands/flows/envVarDeps.test.tssrc/commands/flows/envVarDeps.tssrc/commands/flows/flowRuntimeDeps.test.tssrc/commands/flows/flowRuntimeDeps.tssrc/commands/flows/hybridRun.test.tssrc/commands/flows/hybridRunDefaults.tssrc/commands/flows/runDefaults.handle.test.tssrc/commands/flows/runDefaults.reporterWiring.test.tssrc/commands/flows/runDefaults.tssrc/commands/flows/runStagedFlows.test.tssrc/commands/flows/runStagedFlows.tssrc/commands/flows/runWorker.register.tssrc/domains/emails/configureEmails.test.tssrc/domains/emails/configureEmails.tssrc/domains/runner/flowRuntimeDeps.tssrc/domains/runner/runAndroidFlow.getInbox.fixture.tssrc/domains/runner/runAndroidFlow.test.tssrc/domains/runner/runAndroidFlow.tssrc/domains/runner/runWebFlow.ts
Summary
Stacked on #1372.
FlowRuntimeDeps.env-backed local implementations for:setEnvironmentVariablefetchLatestEnvironmentVariablesgetInboxsupport using either:EMAILER_URL, orflows run --env, and worker subprocessesWhy
Local flows need the same runtime capabilities regardless of architecture. Email inbox access should work for Android and web flows, and should not eagerly load/configure email dependencies unless a flow actually calls
getInbox.Stack
Tests
bun run lintbun run typecheckbun run test src/commands/flows/flowRuntimeDeps.test.ts src/commands/flows/envVarDeps.test.ts src/domains/runner/runWebFlow.test.ts src/domains/runner/runAndroidFlow.test.ts src/commands/flows/runDefaults.handle.test.ts src/commands/flows/hybridRun.test.ts src/commands/flows/runDefaults.reporterWiring.test.ts