Add discovery for custom classes with workflow serialization#859
Conversation
🦋 Changeset detectedLatest commit: 14a46e1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🌍 Community Worlds (161 failed)mongodb (40 failed):
redis (40 failed):
starter (41 failed):
turso (40 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
Pull request overview
This pull request adds automatic discovery of files containing custom serialization classes for the workflow system, eliminating the need for explicit "use workflow" or "use step" directives in files that only define serialization classes.
Changes:
- Added pattern detection for files importing from
@workflow/serdeor usingSymbol.for('workflow-serialize'/'workflow-deserialize') - Updated discovery and transformation logic in builders, Rollup plugin, Next.js loader, and Vite hot-update plugin
- Added comprehensive test coverage for the new pattern detection
- Updated documentation explaining the automatic discovery mechanism
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/vite/src/hot-update.ts | Added serde pattern detection to trigger hot reloads when custom serialization files change |
| packages/swc-plugin-workflow/spec.md | Documented the new automatic file discovery mechanism for custom serialization |
| packages/rollup/src/index.ts | Added serde pattern detection and exclusion patterns for generated files and SDK packages |
| packages/next/src/loader.ts | Added serde pattern detection and exclusion patterns for the Next.js webpack loader |
| packages/next/src/index.ts | Updated Turbopack conditions to detect serde patterns and exclude generated files |
| packages/builders/src/discover-entries-esbuild-plugin.ts | Added serde pattern detection to treat files with custom serialization like step files |
| packages/builders/src/discover-entries-esbuild-plugin.test.ts | Added comprehensive tests for all pattern detection regex patterns |
| .changeset/stale-eagles-pay.md | Added changeset documenting the feature addition |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
packages/next/src/index.ts
Outdated
| { | ||
| content: /(use workflow|use step)/, | ||
| content: | ||
| /(use workflow|use step|from\s+['"]@workflow\/serde['"]|Symbol\.for\s*\(\s*['"]workflow-(?:serialize|deserialize)['"]\s*\))/, |
There was a problem hiding this comment.
The regex pattern for detecting @workflow/serde imports doesn't use backreferences to ensure matching quote types. The pattern from\s+['"]@workflow\/serde['"] would incorrectly match malformed imports like from '@workflow/serde" (mixed quotes).
For consistency with the patterns used in other files (rollup, loader, vite, builders), consider using a backreference pattern like from\s+(['"])@workflow\/serde\1 to ensure the opening and closing quotes match. The same issue applies to the Symbol.for pattern which should use Symbol\.for\s*\(\s*(['"])workflow-(?:serialize|deserialize)\1\s*\) to ensure matching quotes around the symbol name.
| /(use workflow|use step|from\s+['"]@workflow\/serde['"]|Symbol\.for\s*\(\s*['"]workflow-(?:serialize|deserialize)['"]\s*\))/, | |
| /(use workflow|use step|from\s+(['"])@workflow\/serde\2|Symbol\.for\s*\(\s*(['"])workflow-(?:serialize|deserialize)\3\s*\))/, |
packages/rollup/src/index.ts
Outdated
| // These packages are already built and don't need client-side transformation | ||
| // Matches both: node_modules/@workflow/* and monorepo packages/*/dist paths | ||
| const workflowSdkPathPattern = | ||
| /[/\\](?:@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; |
There was a problem hiding this comment.
The workflowSdkPathPattern regex /[/\\](?:@workflow[/\\]|packages[/\\]...) doesn't match its comment which states it "Matches both: node_modules/@workflow/* and monorepo packages/*/dist paths". The regex will match any path containing @workflow[/\\], not just those under node_modules/.
This could incorrectly exclude user files from transformation if they have a directory named @workflow outside of node_modules. For consistency with the builders plugin (line 31-32 in packages/builders/src/discover-entries-esbuild-plugin.ts), consider either:
- Updating the regex to include
node_modulesprefix:/[/\\](?:node_modules[/\\]@workflow[/\\]|packages[/\\]...)/ - Or updating the comment to accurately reflect what the regex matches
| /[/\\](?:@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; | |
| /[/\\](?:node_modules[/\\]@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; |
packages/next/src/loader.ts
Outdated
| // These packages are already built and don't need client-side transformation | ||
| // Matches both: node_modules/@workflow/* and monorepo packages/*/dist paths | ||
| const workflowSdkPathPattern = | ||
| /[/\\](?:@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; |
There was a problem hiding this comment.
The workflowSdkPathPattern regex /[/\\](?:@workflow[/\\]|packages[/\\]...) doesn't match its comment which states it "Matches both: node_modules/@workflow/* and monorepo packages/*/dist paths". The regex will match any path containing @workflow[/\\], not just those under node_modules/.
This could incorrectly exclude user files from transformation if they have a directory named @workflow outside of node_modules. For consistency with the builders plugin (line 31-32 in packages/builders/src/discover-entries-esbuild-plugin.ts), consider either:
- Updating the regex to include
node_modulesprefix:/[/\\](?:node_modules[/\\]@workflow[/\\]|packages[/\\]...)/ - Or updating the comment to accurately reflect what the regex matches
| /[/\\](?:@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; | |
| /[/\\](?:node_modules[/\\]@workflow[/\\]|packages[/\\](?:builders|core|rollup|vite|next|nitro|serde|workflow|swc-plugin-workflow)[/\\])/; |
| // Use 'all' to combine: must match content AND must NOT be in generated path | ||
| all: [ | ||
| // Exclude generated workflow route files from transformation | ||
| { not: { path: /[/\\]\.well-known[/\\]workflow[/\\]/ } }, | ||
| // Match files with workflow directives or custom serialization patterns | ||
| { | ||
| content: /(use workflow|use step)/, | ||
| content: | ||
| /(use workflow|use step|from\s+['"]@workflow\/serde['"]|Symbol\.for\s*\(\s*['"]workflow-(?:serialize|deserialize)['"]\s*\))/, | ||
| }, | ||
| ], |
There was a problem hiding this comment.
The change from using any to all may not properly merge with existing conditions from existingRules[key]?.condition. The previous code (visible in the diff's removed lines) attempted to preserve existing conditions with ...existingRules[key]?.condition and merge with existingRules[key]?.condition.any || [].
The new implementation using all doesn't include any merge logic for pre-existing conditions. If there are existing conditions in existingRules[key], they will be completely overwritten rather than merged. This could break user configurations that already define custom turbopack rules for these file extensions.
Consider preserving existing conditions by merging them appropriately, for example:
- If existing conditions use
all, merge the new conditions into the existingallarray - If existing conditions use
anyor other structures, wrap both old and new conditions appropriately
There was a problem hiding this comment.
This comment is kind of valid but before we most likely still weren't going to match the same conditions if a user configured a loader with same regex so not new and a different regex could be used to avoid conflict by the user.
Create shared transform-utils.ts in @workflow/builders with: - Pattern detection (directives, serde imports, Symbol.for) - Path exclusion checks (generated files, SDK files) - Combined shouldTransformFile logic Update rollup, next, and vite packages to use shared utilities instead of duplicated regex patterns.
VaguelySerious
left a comment
There was a problem hiding this comment.
LGTM but would love @ijjk 's input
Merge activity
|

Added automatic discovery for custom classes with workflow serialization, allowing serialization classes to be defined in separate files without requiring explicit directives.
What changed?
@workflow/serdeSymbol.for('workflow-serialize')orSymbol.for('workflow-deserialize')transform-utils.tsfor consistent pattern detection across all build toolsHow to test?
Why make this change?
Previously, files containing custom serialization classes needed to include a
'use step'directive to be discovered and transformed, even if they weren't actual step functions. This was unintuitive and could lead to confusion.This change allows for a more natural code organization pattern where model classes with serialization can be defined in their own files without requiring directives. The build system will automatically discover and transform these files to ensure the serialization works correctly when the classes are used in workflows or steps.