Skip to content

Fall back to a resolved @get-bb/plugin-sdk entry for the legacy SDK alias in source dev mode - #2335

Open
technicalpickles wants to merge 1 commit into
get-bb:mainfrom
technicalpickles:fix/plugin-sdk-legacy-alias-dev-mode
Open

Fall back to a resolved @get-bb/plugin-sdk entry for the legacy SDK alias in source dev mode#2335
technicalpickles wants to merge 1 commit into
get-bb:mainfrom
technicalpickles:fix/plugin-sdk-legacy-alias-dev-mode

Conversation

@technicalpickles

Copy link
Copy Markdown

What was wrong

pluginSdkAlias in apps/server/src/services/plugins/plugin-runtime.ts only registered the legacy @bb/plugin-sdk specifier alias (kept since the #1574 rename to @get-bb/plugin-sdk) when a prebuilt dist/plugin-sdk-runtime.js bundle existed next to the running module. That bundle is produced only by the server's build script. pnpm dev and pnpm dev:desktop run the server from src/ via tsx and never run build, so pluginSdkAlias silently resolved to undefined in every source dev workflow. Any installed plugin still importing the pre-rename @bb/plugin-sdk specifier (e.g. bb-plugin-dispatch@0.1.3) then failed to load with Cannot find module '@bb/plugin-sdk', even though the same plugin loads fine in a packaged/production build (nightly, npx bb-app). See #2334 for the full repro and log evidence.

What changed

  • apps/server/src/services/plugins/plugin-runtime.ts: extracted resolvePluginSdkAliasTarget(). When the prebuilt runtime bundle is missing, it falls back to import.meta.resolve("@get-bb/plugin-sdk") (the package already resolves naturally in source dev mode per the existing doc comment) and aliases the legacy specifier to that resolved path instead of leaving it unaliased.
  • apps/server/test/services/plugins/plugin-sdk-alias.test.ts: added a test asserting the fallback resolves to the plugin-sdk source entry when no prebuilt bundle is present (this is how the suite always runs, so it exercises the exact dev-mode gap).

No wire/protocol changes, no CLI/doc surface changes — this only affects how the server resolves an internal module alias during plugin loading.

How you verified

  • pnpm exec turbo run typecheck --filter=@bb/server — passes.
  • pnpm exec turbo run test --filter=@bb/server -- --run test/services/plugins/plugin-sdk-alias.test.ts — both tests pass (the new one fails without the fix, since resolvePluginSdkAliasTarget() would return undefined).
  • Manual repro: ran pnpm dev:desktop before the fix and confirmed bb-plugin-dispatch@0.1.3 failed with Cannot find module '@bb/plugin-sdk' in the server log and showed "Failed" in the Extensions UI. Applied the fix, restarted pnpm dev:desktop, confirmed the same plugin now loads (plugin dispatch@0.1.3 loaded in the log) and shows healthy/enabled in the Extensions UI with no error banner.
  • Verified against a clean install in a fresh worktree off main (not just the branch where I found the bug), so this isn't an artifact of leftover state.

Fixes #2334

AGENT GENERATED

…lias in source dev mode

The legacy @bb/plugin-sdk alias only got registered when a prebuilt
dist/plugin-sdk-runtime.js existed next to plugin-runtime.ts. That file
is produced only by the server's build script, so pnpm dev and
pnpm dev:desktop (which run the server from src/ via tsx) never had it,
silently leaving the legacy specifier unaliased. Any installed plugin
still importing the pre-rename @bb/plugin-sdk specifier then failed to
load with "Cannot find module '@bb/plugin-sdk'" in every source dev
workflow, even though the same plugin loads fine in a packaged build.

Fixes get-bb#2334

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015qxKRmfvW9v9jTuC1UK58K
Sign up for free to 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.

Legacy @bb/plugin-sdk alias not registered in source dev mode (pnpm dev / dev:desktop), breaking plugins on the pre-rename specifier

1 participant