Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); Change compiler ID generation logic to use Node.js import specifier by TooTallNate · Pull Request #899 · vercel/workflow · GitHub
Skip to content

Change compiler ID generation logic to use Node.js import specifier - #899

Merged
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier
Feb 4, 2026
Merged

Change compiler ID generation logic to use Node.js import specifier#899
TooTallNate merged 7 commits into
mainfrom
01-30-change_compiler_id_generation_logic_to_use_node.js_import_specifier

Conversation

@TooTallNate

@TooTallNateTooTallNate commented Jan 30, 2026

Copy link
Copy Markdown
Member

Summary

This PR changes how the SWC compiler generates IDs for workflows, steps, and classes. Instead of using raw file paths, IDs are now based on Node.js module specifiers when the file belongs to a package (either in node_modules or a workspace package).

Motivation

Previously, IDs were generated using file paths like step//src/jobs/order.ts//fetchData. This caused several issues:

  1. Package exports conditions: When a package uses conditional exports (e.g., "workflow" vs "default" conditions in package.json), the same import specifier can resolve to different files. Using file paths meant IDs could differ based on which export condition was used.
  2. Cross-bundle consistency: Classes serialized in one bundle couldn't be deserialized in another if the file paths differed.
  3. Version tracking: No way to include package versions in IDs for cache invalidation.

Changes

New ID Format

IDs now use the format {type}//{modulePath}//{identifier} where modulePath is either:

  • A module specifier like point@0.0.1 or @myorg/shared@1.2.3 for package files
  • A relative path prefixed with ./ like ./src/jobs/order for local app files

Examples:

  • step//workflow@4.0.1-beta.50//fetch (SDK step)
  • step//./workflows/order//processOrder (local step)
  • class//point@0.0.1//Point (package class)
  • class//./src/models/User//User (local class)

New Module Specifier Resolution

Added packages/builders/src/module-specifier.ts which:

  • Detects if a file is in node_modules or a workspace package
  • Finds the nearest package.json and extracts name/version
  • Returns the module specifier for the SWC plugin to use

SWC Plugin Changes

  • Added moduleSpecifier option to plugin config
  • Updated naming.rs to support both module specifiers and relative paths
  • Added get_module_path() helper that uses specifier when available, falls back to ./filename format

Special Cases

  • Builtin functions (__builtin_*): Continue to use just the function name as the ID for stable, version-independent lookup from the workflow VM runtime.

Testing

  • Updated all 125+ SWC plugin test fixtures to use new ID format
  • Added tests for module specifier resolution
  • Added tests for Windows path normalization in naming

Breaking Changes

This is technically a breaking change for any persisted workflow runs that reference the old ID format. However, since IDs are internal implementation details and not user-facing, this should not affect end users.

Files Changed

  • packages/builders/src/module-specifier.ts - NEW: Module specifier resolution logic
  • packages/builders/src/apply-swc-transform.ts - Pass module specifier to SWC plugin
  • packages/builders/src/base-builder.ts - Use getImportPath for virtual entry imports
  • packages/swc-plugin-workflow/transform/src/lib.rs - Accept and use module specifier
  • packages/swc-plugin-workflow/transform/src/naming.rs - New ID formatting with module paths
  • packages/swc-plugin-workflow/spec.md - Updated documentation
  • packages/core/e2e/e2e.test.ts - Updated test assertions for new ID format

@changeset-bot

changeset-botBot commented Jan 30, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 2e1b436

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
NameType
@workflow/swc-pluginPatch
@workflow/buildersPatch
@workflow/rollupPatch
@workflow/nextPatch
workflow-devkit-compiler-playgroundPatch
@workflow/astroPatch
@workflow/cliPatch
@workflow/nestPatch
@workflow/nitroPatch
@workflow/sveltekitPatch
@workflow/vitePatch
workflowPatch
@workflow/docs-typecheckPatch
@workflow/world-testingPatch
@workflow/nuxtPatch
@workflow/corePatch
@workflow/web-sharedPatch

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

@github-actions

github-actionsBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

Summary

PassedFailedSkippedTotal
✅ ▲ Vercel Production479038517
✅ 💻 Local Development438032470
✅ 📦 Local Production438032470
✅ 🐘 Local Postgres438032470
✅ 🪟 Windows470047
❌ 🌍 Community Worlds311690200
✅ 📋 Other129012141
Total20001691462315

❌ Failed Tests

🌍 Community Worlds (169 failed)

mongodb (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

redis (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

starter (43 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • health check (CLI) - workflow health command reports healthy endpoints
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

turso (42 failed):

  • addTenWorkflow
  • addTenWorkflow
  • should work with react rendering in step
  • promiseAllWorkflow
  • promiseRaceWorkflow
  • promiseAnyWorkflow
  • readableStreamWorkflow
  • hookWorkflow
  • webhookWorkflow
  • sleepingWorkflow
  • nullByteWorkflow
  • workflowAndStepMetadataWorkflow
  • outputStreamWorkflow
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions
  • fetchWorkflow
  • promiseRaceStressTestWorkflow
  • error handling error propagation workflow errors nested function calls preserve message and stack trace
  • error handling error propagation workflow errors cross-file imports preserve message and stack trace
  • error handling error propagation step errors basic step error preserves message and stack trace
  • error handling error propagation step errors cross-file step error preserves message and function names in stack
  • error handling retry behavior regular Error retries until success
  • error handling retry behavior FatalError fails immediately without retries
  • error handling retry behavior RetryableError respects custom retryAfter delay
  • error handling retry behavior maxRetries=0 disables retries
  • error handling catchability FatalError can be caught and detected with FatalError.is()
  • hookCleanupTestWorkflow - hook token reuse after workflow completion
  • concurrent hook token conflict - two workflows cannot use the same hook token simultaneously
  • stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars)
  • stepFunctionWithClosureWorkflow - step function with closure variables passed as argument
  • closureVariableWorkflow - nested step functions with closure variables
  • spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step
  • pathsAliasWorkflow - TypeScript path aliases resolve correctly
  • Calculator.calculate - static workflow method using static step methods from another class
  • AllInOneService.processNumber - static workflow method using sibling static step methods
  • ChainableService.processWithThis - static step methods using this to reference the class
  • thisSerializationWorkflow - step function invoked with .call() and .apply()
  • customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE
  • instanceMethodStepWorkflow - instance methods with "use step" directive
  • crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context
  • pages router addTenWorkflow via pages router
  • pages router promiseAllWorkflow via pages router
  • pages router sleepingWorkflow via pages router

Details by Category

✅ ▲ Vercel Production
AppPassedFailedSkipped
✅ astro4304
✅ example4304
✅ express4304
✅ fastify4304
✅ hono4304
✅ nextjs-turbopack4601
✅ nextjs-webpack4601
✅ nitro4304
✅ nuxt4304
✅ sveltekit4304
✅ vite4304
✅ 💻 Local Development
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 📦 Local Production
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🐘 Local Postgres
AppPassedFailedSkipped
✅ astro-stable4304
✅ express-stable4304
✅ fastify-stable4304
✅ hono-stable4304
✅ nextjs-turbopack-stable4700
✅ nextjs-webpack-stable4700
✅ nitro-stable4304
✅ nuxt-stable4304
✅ sveltekit-stable4304
✅ vite-stable4304
✅ 🪟 Windows
AppPassedFailedSkipped
✅ nextjs-turbopack4700
❌ 🌍 Community Worlds
AppPassedFailedSkipped
✅ mongodb-dev300
❌ mongodb5420
✅ redis-dev300
❌ redis5420
✅ starter-dev300
❌ starter4430
✅ turso-dev300
❌ turso5420
✅ 📋 Other
AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable4304
✅ e2e-local-postgres-nest-stable4304
✅ e2e-local-prod-nest-stable4304

📋 View full workflow run

@vercel

vercelBot commented Jan 30, 2026

Copy link
Copy Markdown
Contributor

Comment on lines +33 to +35
const root = dirname(dir);

while (dir !== root) {

@vercelvercelBotJan 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function only checks one parent directory due to incorrect loop termination condition, preventing it from finding package.json files in higher directories.

Fix on Vercel

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request changes the compiler's ID generation logic from using file paths to using Node.js import specifiers. The change enables stable workflow/step/class IDs when the same package specifier resolves to different files depending on package.json export conditions.

Changes:

  • Modified ID format from workflow//path/file.ts//functionName to workflow//./path/file//functionName for local files and workflow//packageName@version//functionName for packages
  • Added module_specifier parameter to SWC plugin config to support package-based ID generation
  • Implemented module specifier resolution logic in @workflow/builders to detect node_modules and workspace packages
  • Updated all test fixtures to reflect the new ID format with "./" prefix for local files and stripped extensions

Reviewed changes

Copilot reviewed 139 out of 139 changed files in this pull request and generated 13 comments.

Show a summary per file
FileDescription
packages/swc-plugin-workflow/transform/src/naming.rsCore ID formatting logic, adds module path resolution and extension stripping
packages/swc-plugin-workflow/transform/src/lib.rsIntegration of module_specifier parameter into StepTransform
packages/swc-plugin-workflow/src/lib.rsWASM plugin config with new moduleSpecifier option
packages/builders/src/module-specifier.tsNew module implementing package detection and import path resolution
packages/builders/src/apply-swc-transform.tsPasses module specifier to SWC transform
packages/builders/src/base-builder.tsUses package names for imports to respect export conditions
packages/rollup/src/index.tsIntegration of module specifier resolution
packages/next/src/loader.tsIntegration of module specifier resolution
packages/swc-plugin-workflow/spec.mdUpdated specification with new ID format and examples
Test fixture files (60+ files)All updated to reflect new ID format
packages/core/e2e/e2e.test.tsUpdated regex to match new ID format

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +32 to +33
let dir = dirname(filePath);
const root = dirname(dir);

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The findPackageJson function has a potential infinite loop issue. The termination condition while (dir !== root) where root = dirname(dir) is incorrect. This will cause the loop to never terminate on Unix-like systems where the root is "/", since when dir becomes "/", dirname("/") also returns "/", making dir !== root always true.

The termination condition should check if we've reached the filesystem root by comparing dir with its parent directory, e.g., while (dir !== dirname(dir)).

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
use std::path::PathBuf;
use swc_core::ecma::{
transforms::testing::{FixtureTestConfig, test_fixture},
transforms::testing::{test_fixture, FixtureTestConfig},

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The imports in this file are being reordered. While this doesn't affect functionality, it's a formatting change that should ideally be done separately or avoided if the project doesn't enforce import ordering. The change from FixtureTestConfig, test_fixture to test_fixture, FixtureTestConfig appears to be an alphabetical sorting, but mixing this with functional changes makes the diff harder to review.

Suggested change
transforms::testing::{test_fixture,FixtureTestConfig},
transforms::testing::{FixtureTestConfig, test_fixture},

Copilot uses AI. Check for mistakes.
Comment on lines +88 to +100
const rootPkgPath = join(projectRoot, 'package.json');

// Walk up to find the package.json directory
let dir = dirname(filePath);
while (dir !== dirname(dir)) {
const pkgPath = join(dir, 'package.json');
if (existsSync(pkgPath)) {
// If this is the root package.json, it's not a workspace package
if (pkgPath === rootPkgPath) {
return false;
}
// Found a package.json that's not the root - it's a workspace package
return true;

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path comparison if (pkgPath === rootPkgPath) may not work correctly on Windows due to path separator differences and case sensitivity. The rootPkgPath is created using join(projectRoot, 'package.json'), while pkgPath is created from dir which was derived from filePath. If these paths use different separators (backslashes vs forward slashes) or have different casing, the comparison will fail even when they refer to the same file.

Consider normalizing both paths before comparison, for example:

constnormalizedPkgPath=pkgPath.replace(/\\/g,'/').toLowerCase();constnormalizedRootPkgPath=rootPkgPath.replace(/\\/g,'/').toLowerCase();if(normalizedPkgPath===normalizedRootPkgPath){

Alternatively, use path.resolve() on both paths to ensure they're in the same format.

Copilot uses AI. Check for mistakes.
Comment thread.changeset/rich-symbols-fold.md Outdated
"@workflow/next": patch
---

Change compiler ID generation logic to use Node.js import specifier

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changeset description "Change compiler ID generation logic to use Node.js import specifier" is somewhat vague and doesn't fully explain the impact of this change. Consider expanding it to mention:

  1. This is a breaking change that alters the format of workflow/step/class IDs
  2. IDs now use "./path/to/file" format instead of "path/to/file.ext" for local files
  3. Package files now use "packageName@version" format
  4. This enables stable IDs across different package.json export conditions

This will help users understand the impact when reviewing changelogs.

Suggested change
Change compiler ID generation logic to use Node.js import specifier
Change compiler ID generation logic to use Node.js import specifiers and update ID formats.
This is a breaking change that alters the format of workflow, step, and class IDs:
- Local files now use a "./path/to/file" format instead of "path/to/file.ext".
- Package files now use a "packageName@version" format.
- This enables stable IDs across different package.json export conditions.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable regularArrow.

Copilot uses AI. Check for mistakes.
// Test case: regular function BEFORE step function in same declaration
// This verifies that processing doesn't skip the step function
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegular");
const regularArrow = ()=>1, stepAfterRegular = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegular");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegular.

Copilot uses AI. Check for mistakes.
const regularFn = function() {
return 2;
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//stepAfterRegularFn");
}, stepAfterRegularFn = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//stepAfterRegularFn");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable stepAfterRegularFn.

Copilot uses AI. Check for mistakes.
export async function wflow() {
let count = 42;
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//wflow/namedStepWithClosureVars", ()=>({
var namedStepWithClosureVars = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//wflow/namedStepWithClosureVars", ()=>({

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStepWithClosureVars.

Copilot uses AI. Check for mistakes.
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//namedStep");
export var exportedNamedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//exportedNamedStep");
/**__internal_workflows{"steps":{"input.js":{"exportedNamedStep":{"stepId":"step//./input//exportedNamedStep"},"namedStep":{"stepId":"step//./input//namedStep"}}}}*/;
var namedStep = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//./input//namedStep");

CopilotAIJan 30, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused variable namedStep.

Copilot uses AI. Check for mistakes.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're changing the ID format, it seems like o11y/util code like parseName should be updated in this PR too

@github-actions

github-actionsBot commented Feb 3, 2026

Copy link
Copy Markdown
Contributor

📊 Benchmark Results

📈 Comparing against baseline from main branch. Green 🟢 = faster, Red 🔺 = slower.

workflow with no steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.041s (-8.2% 🟢)1.017s (~)0.976s101.00x
💻 LocalNitro0.042s (-0.7%)1.008s (~)0.966s101.02x
💻 LocalExpress0.043s (-4.5%)1.007s (~)0.964s101.03x
🐘 PostgresNext.js (Turbopack)0.145s (-61.9% 🟢)1.020s (~)0.876s103.51x
🐘 PostgresNitro0.209s (-1.9%)1.015s (~)0.806s105.06x
🐘 PostgresExpress0.263s (+7.7% 🔺)1.014s (~)0.752s106.37x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro0.628s (-12.5% 🟢)1.528s (-13.2% 🟢)0.900s101.00x
▲ VercelNext.js (Turbopack)0.763s (-11.3% 🟢)1.750s (~)0.987s101.22x
▲ VercelExpress0.777s (-1.4%)1.606s (-6.9% 🟢)0.829s101.24x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 1 step

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.090s (~)2.014s (~)0.923s101.00x
💻 LocalExpress1.113s (-0.6%)2.007s (~)0.894s101.02x
💻 LocalNitro1.116s (~)2.008s (~)0.892s101.02x
🐘 PostgresNext.js (Turbopack)1.933s (+3.5%)2.118s (~)0.185s101.77x
🐘 PostgresExpress2.106s (-5.5% 🟢)3.016s (~)0.910s101.93x
🐘 PostgresNitro2.251s (-7.6% 🟢)3.016s (~)0.765s102.06x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.911s (-3.5%)3.733s (-2.8%)0.822s101.00x
▲ VercelExpress2.981s (+3.7%)3.658s (-2.1%)0.677s101.02x
▲ VercelNext.js (Turbopack)3.033s (-2.3%)3.877s (~)0.844s101.04x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

workflow with 10 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)10.728s (~)11.022s (~)0.294s31.00x
💻 LocalExpress10.822s (~)11.010s (~)0.188s31.01x
💻 LocalNitro10.844s (~)11.015s (~)0.172s31.01x
🐘 PostgresNext.js (Turbopack)15.311s (+2.5%)16.040s (+3.3%)0.729s21.43x
🐘 PostgresNitro20.465s (+0.7%)21.038s (~)0.574s21.91x
🐘 PostgresExpress20.513s (~)21.045s (~)0.532s21.91x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro23.281s (-4.0%)23.902s (-5.1% 🟢)0.621s21.00x
▲ VercelNext.js (Turbopack)23.428s (-1.5%)24.191s (-1.4%)0.762s21.01x
▲ VercelExpress23.726s (+1.5%)24.370s (+1.2%)0.644s21.02x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

workflow with 25 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)27.197s (~)28.023s (~)0.826s31.00x
💻 LocalExpress27.447s (~)28.025s (~)0.578s31.01x
💻 LocalNitro27.483s (~)28.025s (~)0.541s31.01x
🐘 PostgresNext.js (Turbopack)37.947s (+2.9%)38.566s (+2.6%)0.620s21.40x
🐘 PostgresNitro50.349s (~)51.087s (~)0.738s21.85x
🐘 PostgresExpress50.447s (~)51.078s (~)0.632s21.85x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express58.086s (-3.7%)58.794s (-3.9%)0.708s21.00x
▲ VercelNitro58.615s (-1.8%)59.797s (-1.2%)1.182s21.01x
▲ VercelNext.js (Turbopack)59.343s (~)59.882s (~)0.540s21.02x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

workflow with 50 sequential steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)56.557s (~)57.058s (~)0.501s21.00x
💻 LocalExpress57.102s (-0.5%)58.039s (~)0.937s21.01x
💻 LocalNitro57.173s (~)58.048s (~)0.875s21.01x
🐘 PostgresNext.js (Turbopack)75.456s (+2.0%)76.102s (+2.7%)0.646s21.33x
🐘 PostgresNitro100.151s (~)100.174s (-1.0%)0.023s11.77x
🐘 PostgresExpress100.321s (~)101.170s (~)0.849s11.77x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro124.927s (+4.4%)125.467s (+3.9%)0.540s11.00x
▲ VercelNext.js (Turbopack)132.389s (+9.0% 🔺)133.132s (+8.6% 🔺)0.743s11.06x
▲ VercelExpress132.828s (+8.3% 🔺)133.822s (+8.5% 🔺)0.994s11.06x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.all with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)1.390s (~)2.011s (~)0.621s151.00x
💻 LocalExpress1.407s (-1.5%)2.006s (~)0.599s151.01x
💻 LocalNitro1.417s (~)2.007s (~)0.590s151.02x
🐘 PostgresNext.js (Turbopack)1.842s (-9.5% 🟢)2.080s (-20.2% 🟢)0.238s151.33x
🐘 PostgresNitro2.220s (-4.7%)3.014s (~)0.794s101.60x
🐘 PostgresExpress2.413s (+3.8%)3.014s (~)0.601s101.74x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.852s (~)3.687s (-3.9%)0.836s91.00x
▲ VercelNitro3.207s (+6.8% 🔺)3.977s (+1.0%)0.770s81.12x
▲ VercelNext.js (Turbopack)3.280s (+5.6% 🔺)4.027s (+6.0% 🔺)0.747s81.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Promise.all with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.394s (-4.8%)3.039s (~)0.645s101.00x
💻 LocalExpress2.581s (-0.5%)3.016s (~)0.435s101.08x
💻 LocalNitro2.663s (+3.8%)3.011s (~)0.349s101.11x
🐘 PostgresExpress8.095s (-15.3% 🟢)8.527s (-18.2% 🟢)0.432s43.38x
🐘 PostgresNitro8.727s (+5.7% 🔺)9.328s (+3.1%)0.601s43.64x
🐘 PostgresNext.js (Turbopack)11.069s (-11.6% 🟢)11.716s (-7.7% 🟢)0.647s34.62x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.200s (-2.1%)3.881s (-6.7% 🟢)0.681s81.00x
▲ VercelNext.js (Turbopack)3.459s (-1.0%)4.297s (+0.9%)0.838s71.08x
▲ VercelNitro3.550s (~)4.213s (-2.6%)0.663s81.11x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.all with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)6.960s (~)8.007s (-1.1%)1.047s41.00x
💻 LocalExpress7.353s (-2.1%)8.330s (-2.0%)0.977s41.06x
💻 LocalNitro7.794s (+6.7% 🔺)8.744s (+8.4% 🔺)0.950s41.12x
🐘 PostgresExpress44.598s (-1.2%)45.079s (-0.6%)0.481s16.41x
🐘 PostgresNitro46.431s (-4.0%)47.255s (-3.9%)0.824s16.67x
🐘 PostgresNext.js (Turbopack)53.190s (+2.5%)53.291s (+2.2%)0.101s17.64x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro4.035s (+22.5% 🔺)4.712s (+21.7% 🔺)0.677s81.00x
▲ VercelExpress5.087s (+47.2% 🔺)5.843s (+44.1% 🔺)0.756s61.26x
▲ VercelNext.js (Turbopack)5.686s (+63.3% 🔺)6.601s (+51.6% 🔺)0.915s51.41x

🔍 Observability: Nitro | Express | Next.js (Turbopack)

Promise.race with 10 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Express1.429s (-1.3%)2.006s (~)0.577s151.00x
💻 LocalNitro1.438s (~)2.006s (~)0.568s151.01x
💻 LocalNext.js (Turbopack)1.441s (+1.8%)2.010s (~)0.569s151.01x
🐘 PostgresNext.js (Turbopack)1.931s (-10.9% 🟢)2.323s (-7.9% 🟢)0.392s131.35x
🐘 PostgresNitro2.100s (+6.2% 🔺)2.939s (+37.1% 🔺)0.839s111.47x
🐘 PostgresExpress2.163s (+3.5%)2.602s (~)0.439s121.51x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express2.906s (+2.4%)3.796s (~)0.890s81.00x
▲ VercelNext.js (Turbopack)2.957s (+1.0%)3.866s (+2.3%)0.909s81.02x
▲ VercelNitro3.317s (+17.7% 🔺)4.144s (+10.1% 🔺)0.827s81.14x

🔍 Observability: Express | Next.js (Turbopack) | Nitro

Promise.race with 25 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)2.692s (+1.9%)3.018s (~)0.325s101.00x
💻 LocalNitro2.716s (-2.0%)3.015s (~)0.299s101.01x
💻 LocalExpress2.716s (+0.6%)3.014s (~)0.297s101.01x
🐘 PostgresNext.js (Turbopack)10.121s (-20.2% 🟢)10.689s (-20.1% 🟢)0.568s33.76x
🐘 PostgresNitro11.043s (+6.2% 🔺)11.379s (+3.2%)0.336s34.10x
🐘 PostgresExpress11.962s (+9.7% 🔺)12.360s (+5.5% 🔺)0.398s34.44x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro2.958s (-3.7%)3.665s (-5.3% 🟢)0.708s91.00x
▲ VercelNext.js (Turbopack)3.026s (-2.5%)3.808s (-1.9%)0.782s81.02x
▲ VercelExpress3.049s (~)3.764s (-0.8%)0.715s91.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Promise.race with 50 concurrent steps

💻 Local Development

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)7.960s (+7.4% 🔺)8.805s (+5.2% 🔺)0.844s41.00x
💻 LocalNitro8.068s (+4.5%)8.395s (-3.5%)0.328s41.01x
💻 LocalExpress8.124s (+1.2%)8.643s (-3.4%)0.519s41.02x
🐘 PostgresNext.js (Turbopack)50.171s (-12.8% 🟢)51.091s (-12.2% 🟢)0.920s16.30x
🐘 PostgresNitro51.180s (+1.1%)52.119s (+1.5%)0.939s16.43x
🐘 PostgresExpress53.012s (+11.2% 🔺)53.093s (+10.0% 🔺)0.081s16.66x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Express3.221s (-7.5% 🟢)3.807s (-8.1% 🟢)0.586s81.00x
▲ VercelNitro3.659s (+13.5% 🔺)4.340s (+12.2% 🔺)0.681s71.14x
▲ VercelNext.js (Turbopack)3.712s (-5.4% 🟢)4.624s (-0.6%)0.912s71.15x

🔍 Observability: Express | Nitro | Next.js (Turbopack)

Stream Benchmarks(includes TTFB metrics)
workflow with stream

💻 Local Development

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
💻 Local🥇 Next.js (Turbopack)0.150s (+3.7%)1.003s (~)0.015s (-8.9% 🟢)1.026s (~)0.877s101.00x
💻 LocalExpress0.176s (-6.1% 🟢)0.992s (~)0.014s (-11.6% 🟢)1.020s (~)0.844s101.18x
💻 LocalNitro0.180s (-1.9%)0.992s (~)0.014s (~)1.021s (~)0.841s101.20x
🐘 PostgresNext.js (Turbopack)1.140s (+71.2% 🔺)1.905s (+96.3% 🔺)0.000s (NaN%)2.016s (+98.6% 🔺)0.876s107.62x
🐘 PostgresNitro2.321s (+4.8%)2.725s (-3.7%)0.000s (-100.0% 🟢)3.018s (~)0.696s1015.52x
🐘 PostgresExpress2.332s (-3.1%)2.708s (+2.4%)0.000s (+Infinity% 🔺)3.020s (~)0.688s1015.59x

▲ Production (Vercel)

WorldFrameworkWorkflow TimeTTFBSlurpWall TimeOverheadSamplesvs Fastest
▲ Vercel🥇 Nitro3.115s (+1.0%)3.341s (-3.0%)0.193s (+40.8% 🔺)4.041s (-2.1%)0.926s101.00x
▲ VercelNext.js (Turbopack)3.185s (+2.1%)3.263s (+0.7%)0.249s (+66.2% 🔺)4.042s (+4.1%)0.857s101.02x
▲ VercelExpress3.206s (+3.3%)3.410s (+3.0%)0.227s (+19.1% 🔺)4.158s (+3.4%)0.952s101.03x

🔍 Observability: Nitro | Next.js (Turbopack) | Express

Summary

Fastest Framework by World

Winner determined by most benchmark wins

World🥇 Fastest FrameworkWins
💻 LocalNext.js (Turbopack)11/12
🐘 PostgresNext.js (Turbopack)10/12
▲ VercelNitro7/12
Fastest World by Framework

Winner determined by most benchmark wins

Framework🥇 Fastest WorldWins
Express💻 Local10/12
Next.js (Turbopack)💻 Local10/12
Nitro💻 Local10/12
Column Definitions
  • Workflow Time: Runtime reported by workflow (completedAt - createdAt) - primary metric
  • TTFB: Time to First Byte - time from workflow start until first stream byte received (stream benchmarks only)
  • Slurp: Time from first byte to complete stream consumption (stream benchmarks only)
  • Wall Time: Total testbench time (trigger workflow + poll for result)
  • Overhead: Testbench overhead (Wall Time - Workflow Time)
  • Samples: Number of benchmark iterations run
  • vs Fastest: How much slower compared to the fastest configuration for this benchmark

Worlds:

  • 💻 Local: In-memory filesystem world (local development)
  • 🐘 Postgres: PostgreSQL database world (local development)
  • ▲ Vercel: Vercel production/preview deployment
  • 🌐 Starter: Community world (local development)
  • 🌐 Turso: Community world (local development)
  • 🌐 MongoDB: Community world (local development)
  • 🌐 Redis: Community world (local development)
  • 🌐 Jazz: Community world (local development)

📋 View full workflow run

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@TooTallNate@VaguelySerious