cli: restore dynamic world loading for community backends#2806
Merged
Conversation
Since #2752 moved world selection to static injection, setupCliWorld only constructed the vercel, local, and postgres worlds explicitly and threw 'Unsupported workflow backend' for anything else — breaking community worlds (e.g. @workflow-worlds/turso) that previously loaded through the dynamic createWorld() in @workflow/core/runtime. Generalize the postgres-only dynamic path: any backend other than vercel/local is now resolved from the user's project directory and loaded via its createWorld() export, matching @workflow/web's world construction (#2804), with clear errors when the package is missing or does not export createWorld(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 0a0cc4d The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 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 |
Contributor
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
❌ Some E2E test jobs failed:
Check the workflow run for details. |
Review feedback on #2804: import() of a require-resolved CJS entry relies on cjs-module-lexer to surface named exports; fall back to mod.default.createWorld when detection fails. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
karthikscale3
added a commit
that referenced
this pull request
Jul 7, 2026
Review feedback: import() of a require-resolved CJS entry relies on cjs-module-lexer to surface named exports; fall back to mod.default.createWorld when detection fails. Mirrored in the CLI in #2806. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
VaguelySerious
approved these changes
Jul 7, 2026
karthikscale3
added a commit
that referenced
this pull request
Jul 7, 2026
…#2804) * web: construct worlds explicitly instead of via static-injection stub Since #2752, createWorld() from @workflow/core/runtime is a stub that throws unless a framework build plugin aliases it to a world package. The CLI was migrated to construct worlds directly, but @workflow/web still called the stub, so 'workflow web' crashed with 'Workflow target world was not statically injected' for local and postgres backends (the vercel path was unaffected since it constructs the world directly). Mirror the CLI: import the local world statically and resolve any other configured world package from the inspected project's directory. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * web: fall back to default.createWorld for CJS world packages Review feedback: import() of a require-resolved CJS entry relies on cjs-module-lexer to surface named exports; fall back to mod.default.createWorld when detection fails. Mirrored in the CLI in #2806. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
No backport to This commit fixes a regression introduced by #2752 (static world injection), which is a To override, re-run the Backport to stable workflow manually via |
This was referenced Jul 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Follow-up to #2804, fixing the same class of #2752 regression on the CLI side.
Since #2752 moved world selection to static injection,
setupCliWorld(packages/cli/src/lib/inspect/setup.ts) only constructs the vercel, local, and postgres worlds explicitly and throws for anything else:Before #2752, any non-vercel backend fell through to the dynamic
createWorld()loader in@workflow/core/runtime, so community worlds (@workflow-worlds/turso,@workflow-worlds/mongodb,@workflow-worlds/redis,workflow-world-jazz, …) worked withworkflow inspect/workflow web. The--backendflag help still advertises<your-package-name>, and@workflow/webships an env allowlist for these worlds — they're a supported configuration.Fix
Generalize the postgres-only dynamic path (
createPostgresCliWorld) intocreateDynamicCliWorld(backendId): any backend other than vercel/local is resolved from the user's project directory viacreateRequire().resolve()and loaded through itscreateWorld()export — the same construction@workflow/webuses after #2804 — with clear errors when the package isn't installed or doesn't exportcreateWorld().The vercel, local, and postgres (
@workflow/world-postgresresolves through the identical code it used before) paths are behaviorally unchanged.Validation
tsc --noEmiton@workflow/cli— cleanbiome checkon the changed file — only the pre-existingsetupCliWorldcomplexity warning, present onmain@workflow-worlds/fakeworldpackage exportingcreateWorld()is resolved from the project'snode_modulesand constructed; a missing package producesCould not resolve workflow backend package …; a package without the export produces… does not export createWorld()Follow-up
This helper is now line-for-line the shape of
createWorldForBackendin@workflow/web(#2804). Once both land, extracting a shared resolver (e.g. into@workflow/utils, guarded for Node-only usage) would keep them from drifting.🤖 Generated with Claude Code