Draft
Conversation
Complete rewrite of the workflow engine from DAG-based WorkflowDefinition objects to the 'use workflow' / step() directive pattern inspired by Vercel's Workflow DevKit (useworkflow.dev). Key changes: - @c4c/workflow: New runtime with start(), step(), FatalError, RetryableError, sleep(), createHook(), getStepMetadata(), getWorkflowMetadata(), getWritable() - Workflows are now plain async functions with 'use workflow' directive - Steps use step() wrapper for automatic retry semantics - Standard JS patterns (Promise.all, Promise.race, try/catch, loops) for control flow instead of condition/parallel/sequential node types - Event system for real-time monitoring (subscribeToRun, subscribeToAll) - Hook system for workflow suspension/resumption - Duration parser for human-readable time strings Removed: - Old builder pattern (workflow().step().commit()) - WorkflowDefinition/WorkflowNode types - DAG traversal runtime - OpenTelemetry span collector (can be added back as needed) - TriggerWorkflowManager (replaced by createHook pattern) - SubWorkflow system (just call workflow functions directly) Updated: - All examples converted to new pattern - @c4c/adapters workflow HTTP router updated - @c4c/workflow-react hooks updated - @c4c/generators removed old workflow dependency No backward compatibility - clean break to new paradigm. Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
- Update CLI exec command to use new start() API - Remove old WorkflowDefinition type references from CLI formatting - Update workflow app components (TraceViewer, SpanGanttChart, WorkflowVisualizer) to use local type definitions instead of removed @c4c/workflow types - Rewrite workflows documentation with new patterns - Update README with new workflow API examples - Update @c4c/workflow package docs Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
|
Cursor Agent can help with this pull request. Just |
Replace our custom runtime with the actual 'workflow' npm package from Vercel (useworkflow.dev). This adopts the full three-endpoint architecture: Architecture (from useworkflow.dev framework-integrations docs): - Build-time: SWC transforms 'use workflow'/'use step' into bundles - flow.js (workflow orchestration in sandboxed VM) - step.js (step execution with full Node.js access) - webhook.js (webhook delivery) - Runtime: Three HTTP endpoints at .well-known/workflow/v1/ - Client mode: SWC transform for type-safe start() references Changes: - @c4c/workflow now re-exports from 'workflow' npm package (FatalError, RetryableError, sleep, createHook, createWebhook, defineHook, getStepMetadata, getWorkflowMetadata, getWritable) - Removed custom runtime, context, errors, hooks, sleep implementations (all handled by the workflow package now) - Kept c4c extensions: event system, execution store, duration parser - All examples updated to use real 'use step' directive instead of step() - Adapters updated for three-endpoint architecture - Added workflow + @workflow/world-local as workspace dependencies - Documentation updated to reflect framework integration pattern Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
End-to-end tests for the Vercel Workflow DevKit integration.
Test structure (4 phases):
Phase 1 — Build (7 tests):
Verifies `workflow build` generates flow.js, step.js, webhook.js,
and manifest.json with correct workflow/step IDs.
Phase 2 — ESM handlers (3 tests):
Verifies generated CJS bundles load via ESM wrappers (.mjs)
and export POST handlers.
Phase 3 — Runtime server (4 tests):
Node HTTP server serves .well-known/workflow/v1/ endpoints.
Health check, flow POST, step POST, 404 handling.
Phase 4 — Workflow execution (8 tests):
Full end-to-end via start() + pollReturnValue():
- simpleWorkflow: sequential add+multiply
- parallelWorkflow: Promise.all with 3 parallel steps
- conditionalWorkflow: if/else branching (both branches)
- errorWorkflow: FatalError propagation
- loopWorkflow: iterative step calls
- sleepWorkflow: durable sleep("1s")
- raceWorkflow: Promise.race
Uses @workflow/world-local for file-based storage backend.
ESM wrappers generated via scripts/cjs-to-esm.mjs post-build.
Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
DELETED (6100+ lines of dead code): - @c4c/core — procedures, contracts, registry, executor, metadata, triggers - @c4c/policies — withRetry, withAuth, withLogging, withSpan, withOAuth, withRateLimit - @c4c/generators — OpenAPI generation, client generation, trigger generation - @c4c/workflow-react — old React hooks tied to procedure-based workflows - apps/workflow — Next.js UI app tied to old WorkflowDefinition types - All procedures/ directories from every example - CLI commands: exec, generate, integrate, export-spec - CLI lib: registry, watcher, server, formatting, completion, etc. - Adapters: RPC, REST, CLI adapter, webhook router, HTTP server (Hono-based) - examples/modules, examples/cross-integration, examples/integrations, examples/triggers KEPT (332 lines that actually work): - @c4c/workflow (26 lines) — thin re-export of 'workflow' npm package - @c4c/adapters (166 lines) — HTTP server for .well-known/workflow/v1/ endpoints - CLI (140 lines) — c4c dev/build/serve wrapping workflow CLI - examples/basic — pure 'use workflow'/'use step' examples - tests/workflow-integration — 22 passing end-to-end tests The project is now a clean wrapper around useworkflow.dev with no dead code. Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
Remove all old VitePress documentation (procedures, policies, generators, etc). Rewrite README to reflect the actual project: pure useworkflow.dev wrapper. Project is now 332 lines of code + 22 passing tests. Co-authored-by: Roman Popov <Pom4H@users.noreply.github.com>
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.
Replaced the entire workflow engine with the Workflow DevKit (useworkflow.dev) paradigm for building durable workflows using plain TypeScript functions.
The previous workflow engine relied on a custom declarative DAG-based DSL, which introduced complexity for control flow and error handling. This PR migrates to the Workflow DevKit approach, where workflows are standard async functions and steps are wrapped with
step()for automatic durability and retries. This shift simplifies workflow definition by leveraging native JavaScript constructs (e.g.,if/elsefor conditions,Promise.allfor parallelism) and significantly enhances the developer experience. This change is intentionally non-backward compatible and impacts@c4c/workflow,@c4c/adapters,@c4c/workflow-react,apps/cli,apps/workflow, and all examples and documentation.