Allow synchronous functions to use "use step" directive#1633
Conversation
…/private
The SWC compiler plugin no longer generates import statements. All step
function registrations and closure variable access are now self-contained
inline IIFEs with zero module dependencies:
- Step registration uses an IIFE that writes to
globalThis[Symbol.for('@workflow/core//registeredSteps')]
- Closure variable access uses an IIFE that reads from
globalThis[Symbol.for('WORKFLOW_STEP_CONTEXT_STORAGE')]
- Registrations are placed immediately after each function definition
instead of being batched at the bottom of the file
This enables 3rd-party node_modules packages to define step functions
without needing the 'workflow' package available at runtime.
Also removes the @workflow/core/private and workflow/internal/private
public subpath exports since they are no longer referenced by generated
code.
Lift the async function restriction from "use step" in both the SWC compiler plugin and the TypeScript language service plugin. This enables using "use step" as a mechanism to strip Node.js-dependent code from the workflow VM bundle without requiring the function to be async. The async restriction is preserved for "use workflow" functions. - SWC plugin: removed async guards from all step function code paths, updated should_transform_function, updated InvalidExport validation - TypeScript plugin: removed error 9002 for sync step functions - Added sync-step fixture test, cleaned up error test fixtures - Updated spec.md error documentation
🦋 Changeset detectedLatest commit: e4b8d29 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (65 failed)mongodb (4 failed):
redis (3 failed):
turso (58 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
There was a problem hiding this comment.
Pull request overview
This PR removes the “step functions must be async” restriction across the SWC transform and the TypeScript language service plugin, allowing synchronous functions to use the "use step" directive as a code-stripping mechanism while preserving the async requirement for "use workflow".
Changes:
- TypeScript plugin: removes diagnostic error 9002 for synchronous step functions and updates tests accordingly.
- SWC plugin: lifts async-only checks from
"use step"transformation paths and adds a newsync-stepfixture to verify output across workflow/step/client modes. - Documentation + release: updates SWC plugin spec validation table and adds a changeset for patch releases.
Reviewed changes
Copilot reviewed 23 out of 23 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/typescript-plugin/src/diagnostics.ts | Removes async validation for "use step" functions in custom diagnostics. |
| packages/typescript-plugin/src/diagnostics.test.ts | Updates tests to assert no error 9002 for sync step functions. |
| packages/swc-plugin-workflow/transform/tests/fixture/sync-step/input.js | Adds fixture input covering sync function/arrow/object-method step directives. |
| packages/swc-plugin-workflow/transform/tests/fixture/sync-step/output-workflow.js | Expected workflow-mode output for sync-step fixture (initializer exports). |
| packages/swc-plugin-workflow/transform/tests/fixture/sync-step/output-step.js | Expected step-mode output for sync-step fixture (registration + preserved bodies). |
| packages/swc-plugin-workflow/transform/tests/fixture/sync-step/output-client.js | Expected client-mode output for sync-step fixture (stepId annotations). |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/input.js | Updates error fixture to only cover non-async "use workflow" cases. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-workflow.js | Updates expected workflow-mode output after removing step async restriction. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-workflow.stderr | Updates expected stderr to reflect only "use workflow" async errors. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-step.js | Updates expected step-mode output after removing step async restriction. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-step.stderr | Updates expected stderr to reflect only "use workflow" async errors. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-client.js | Updates expected client-mode output after removing step async restriction. |
| packages/swc-plugin-workflow/transform/tests/errors/non-async-functions/output-client.stderr | Updates expected stderr to reflect only "use workflow" async errors. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/input.js | Updates invalid-export fixture to allow sync function exports in "use step" files. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-workflow.js | Expected workflow-mode output reflecting sync function export allowance. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-workflow.stderr | Expected stderr after invalid-export fixture adjustments. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-step.js | Expected step-mode output registering sync exported steps. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-step.stderr | Expected stderr after invalid-export fixture adjustments. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-client.js | Expected client-mode output with stepId for sync exported steps. |
| packages/swc-plugin-workflow/transform/tests/errors/invalid-exports/output-client.stderr | Expected stderr after invalid-export fixture adjustments. |
| packages/swc-plugin-workflow/transform/src/lib.rs | Removes async guards for "use step" transformations; keeps "use workflow" async enforcement in relevant paths. |
| packages/swc-plugin-workflow/spec.md | Updates validation error documentation to reflect sync "use step" allowance. |
| .changeset/allow-sync-step-functions.md | Adds patch changeset entries for SWC + TypeScript plugins. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…row behavior - Remove stale 'Collect registration calls' comment from StepTransform - Fix 'everyhwere' typo in e2e test comments - Closure vars IIFE now throws when called outside a step function context, matching the original __private_getClosureVars behavior
…xport message - Remove the no-op validate_async_function method and unwrap all callers - InvalidExport message now says 'Only functions can be exported' for 'use step' files, vs 'Only async functions' for 'use workflow' files
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: blocking issues found
…ethod async check - Remove validate_async_function() entirely and unwrap all 8 call sites (the function was a no-op that always returned true) - Fix static class method handler to only check async for 'use workflow' (was still blocking sync step functions on static methods) - Remove no-op checkStepFunction from TypeScript plugin - Regenerate test fixture outputs
Also bump changeset from patch to minor (new feature, not bug fix)
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 22 out of 22 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Previously validated that step functions must be async. The restriction | ||
|
|
There was a problem hiding this comment.
There’s a dangling/incomplete comment here (ends mid-sentence) left over from removing the async-only validation. It should either be completed to explain the new behavior or removed to avoid confusion when maintaining this transform logic.
| // Previously validated that step functions must be async. The restriction |
There was a problem hiding this comment.
Fixed in #1664 — removed the dangling incomplete comment entirely.
| // Validate exports if we have a file-level workflow directive. | ||
| // Step files allow any exports (sync or async), but workflow files | ||
| // require exported functions to be async. | ||
| if self.has_file_workflow_directive { |
There was a problem hiding this comment.
visit_mut_module_items no longer validates exports for module-level 'use step' files, which means non-function exports (constants/classes/re-exports) are now allowed even though they won’t be code-stripped and can easily pull Node-only code into the workflow/client bundles. Consider adding a separate validation branch for has_file_step_directive that allows sync or async functions but rejects non-function exports/re-exports, with an error message that matches that rule.
There was a problem hiding this comment.
Fixed in #1664 — added export validation for has_file_step_directive that allows sync/async function exports but rejects non-function exports (constants, classes, re-exports). Error message is "Only functions can be exported from a \"use step\" file".
| // These should all error - not functions | ||
| export const value = 42; | ||
| export function syncFunc() { | ||
| return 'not allowed'; | ||
| } | ||
| export class MyClass { | ||
| method() {} | ||
| } | ||
| export * from './other'; |
There was a problem hiding this comment.
The header comment says these exports “should all error”, but the expected stderr fixtures for this test case were removed and the outputs keep these exports. Please update the comment (and potentially relocate/rename this fixture since it no longer asserts an error) so the test intent matches the actual expected behavior.
There was a problem hiding this comment.
Fixed in #1664 — the comment is now correct again since export validation for step files has been restored. The const value, class MyClass, and export * all produce errors; the sync and async function exports pass.
| "@workflow/typescript-plugin": minor | ||
| --- | ||
|
|
||
| Allow synchronous functions to use `"use step"` directive. This enables using `"use step"` as a mechanism to strip Node.js-dependent code from the workflow VM bundle without requiring the function to be async. |
There was a problem hiding this comment.
The PR description mentions that packages/swc-plugin-workflow/spec.md error documentation was updated, but this PR diff doesn’t include any changes to that spec file. Please ensure the spec is updated to reflect that "use step" can be used on sync functions while "use workflow" remains async-only (and adjust any validation/export rules accordingly).
There was a problem hiding this comment.
Fixed in #1664 — updated spec.md error table (split Non-async into workflow-only, added step export validation row) and supported function forms (added sync variants for all step function forms).
Summary
"use step"in both the SWC compiler plugin and the TypeScript language service plugin"use step"to strip their Node.js-dependent code from the workflow VM bundle"use workflow"functionsMotivation
This enables using
"use step"as a code-stripping mechanism for synchronous methods (e.g.getReadable()on theRunclass) that use Node.js APIs not available in the workflow VM. Previously,"use step"required the function to be async, which was an artificial restriction for this use case.Changed packages
@workflow/swc-plugin— Removed async guards from all step function code paths; updatedshould_transform_function; updatedInvalidExportvalidation for module-level"use step"files; addedsync-stepfixture test; cleaned up error test fixtures@workflow/typescript-plugin— Removed error 9002 (sync step function diagnostic); updated testsspec.mderror documentationTest plan
sync-stepfixture)