Skip to content

De-emphasize codemode package invocation bridge - #472

Merged
kentcdodds merged 3 commits into
mainfrom
de-emphasize-codemode-package-invocation
May 14, 2026
Merged

kentcdodds merged 3 commits into
mainfrom
de-emphasize-codemode-package-invocation

Conversation

@kentcdodds

@kentcdodds kentcdodds commented May 14, 2026 •

Copy link
Copy Markdown
Member

Summary

  • route packages.check, packages.invoke, and packages.invokeChecked through a private runtime bridge provider instead of synthetic codemode.package_invoke_* tools
  • remove package invocation bridge functions from the public codemode provider surface
  • update runtime/registry tests to verify packages.* still works while direct codemode.package_invoke_checked rejects
  • address AI-reviewer feedback by making bridge-provider and direct-rejection test expectations clearer

Testing

  • npx vitest run --project node-unit "packages/worker/src/mcp/run-codemode-registry.node.test.ts"
  • npx vitest run --project workers-unit "packages/worker/src/package-runtime/module-graph.workers.test.ts"
  • npm run validate
  • PR CI: ✅ Validate, 🔎 Deploy Preview Resources, CodeRabbit, and Cursor Bugbot passing

Closes #470

Open in Web Open in Cursor 

Summary by CodeRabbit

  • Tests

    • Enhanced test coverage for bundled module execution and package invocation
    • Extended test scenarios to verify package invocation behavior across runtime configurations
    • Added verification for direct package invocation checked calls
  • Refactor

    • Restructured internal package invocation routing through dedicated bridge mechanism

Review Change Stack

Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
@coderabbitai

coderabbitai Bot commented May 14, 2026 •

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

This PR refactors how package invoke functionality is exposed at runtime. Package invoke calls are moved from public codemode.package_invoke_* tools to a dedicated private __kodyPackageInvokeRuntimeBridge provider, decoupling the public packages helper from the codemode namespace while preserving the same runtime behavior through conditional provider registration.

Changes

Package invoke runtime bridge refactor

Layer / File(s) Summary
Create package invoke runtime bridge provider
packages/worker/src/mcp/run-codemode-registry.ts
Introduce createPackageInvokeRuntimeBridgeProvider() function and update the packages helper prelude to route check, invoke, and invokeChecked calls to the bridge provider instead of codemode tools.
Remove package invoke tools from codemode provider
packages/worker/src/mcp/run-codemode-registry.ts
Remove packageInvokeTools option from buildCodemodeFns and buildCodemodeProvider signatures, and stop registering package_invoke_check, package_invoke, and package_invoke_checked tools in the codemode provider.
Register bridge provider in execution
packages/worker/src/mcp/run-codemode-registry.ts
Update runCodemodeWithRegistry and runBundledModuleWithRegistry to conditionally add the bridge provider to the executor's providers list when packageInvokeTools are provided.
Test private bridge wiring in runBundledModuleWithRegistry
packages/worker/src/mcp/run-codemode-registry.node.test.ts
Verify that when packageInvokeTools are provided, the bundled runtime includes __kodyPackageInvokeRuntimeBridge and the executor receives two providers. Assertions confirm that package_invoke_* tools are not on the codemode provider but accessible via the bridge.
Integration test coverage of bridge provider
packages/worker/src/package-runtime/module-graph.workers.test.ts
Extend saved package execution and ad hoc execution tests to directly exercise codemode.package_invoke_checked through the bridge, verifying the bridge provider correctly exposes the expected tool functions.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

  • kentcdodds/kody#429: Implements packages.invoke/package runtime invocation wiring in the codemode runtime registry layer that this PR refactors to use the private bridge provider.
  • kentcdodds/kody#435: Rewires newly added checked dynamic invocation paths (packages.check/packages.invokeChecked and codemode.package_invoke_check/codemode.package_invoke_checked) to route via the private __kodyPackageInvokeRuntimeBridge.
  • kentcdodds/kody#434: Verifies bundled runtime/package-invoke behavior when package invoke tools are present; this PR extends those assertions with the private bridge routing.

Poem

🐰 A bridge in the shadows, so private and sleek,
Whisks packages away from the codemode critique,
No more public tools cluttering the view—
Just helper and helper, doing what they do! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title 'De-emphasize codemode package invocation bridge' accurately describes the main change: shifting package invocation calls from the public codemode namespace to a private runtime bridge.
Linked Issues check ✅ Passed The PR fulfills all coding objectives from issue #470: routes package invocation through a private bridge, removes package_invoke_* from the codemode provider, and updates tests to verify the new behavior works correctly.
Out of Scope Changes check ✅ Passed All changes are scoped to implementing the private bridge for package invocation. The test updates and function signature changes directly support the refactoring objective without introducing unrelated modifications.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch de-emphasize-codemode-package-invocation

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
@kentcdodds
kentcdodds marked this pull request as ready for review May 14, 2026 18:03
@github-actions

github-actions Bot commented May 14, 2026 •

Copy link
Copy Markdown
Contributor

🔎 Preview deployed: https://kody-pr-472.kentcdodds.workers.dev

Worker: kody-pr-472
D1: kody-pr-472-db
KV: kody-pr-472-oauth-kv

Mocks:

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🧹 Nitpick comments (5)
packages/worker/src/mcp/run-codemode-registry.node.test.ts (1)

1557-1573: ⚡ Quick win

Assert provider cardinality before indexing bridge provider.

The test reads providers[1] directly; add an explicit length check so bridge registration regressions fail with a clearer contract-level message.

Proposed tweak
 			async execute(wrapped, providers) {
+				expect(providers).toHaveLength(2)
 				expect(wrapped).toContain('const packages = {')
 				expect(wrapped).toContain('__kodyPackageInvokeRuntimeBridge')
 				expect(wrapped).not.toContain('codemode.package_invoke')
 				expect(wrapped).toContain(
 					"packages: typeof packages === 'undefined' ? null : packages",
 				)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/worker/src/mcp/run-codemode-registry.node.test.ts` around lines 1557
- 1573, The test's execute(...) callback indexes providers[1] without asserting
providers length first; add an explicit assertion on providers (e.g.,
expect(providers).toHaveLength(expected) or
expect(providers.length).toBeGreaterThan(1)) before assigning providerFns and
packageBridgeFns so a missing bridge provider fails with a clear contract-level
message; update the block around execute(wrapped, providers) to assert
providers' cardinality prior to using providers[0] and providers[1] (references:
execute, providers, providerFns, packageBridgeFns).
packages/worker/src/package-runtime/module-graph.workers.test.ts (4)

573-582: ⚡ Quick win

Consider adding a comment explaining the expected rejection.

This code tests that direct calls to codemode.package_invoke_checked are rejected, which is a key behavioral change in this PR. A brief comment would help future maintainers understand why this test expects failure rather than success.

📝 Suggested comment
+	// Direct codemode.package_invoke_checked calls should reject; packages.invokeChecked is the public API
 	let directCodemodeInvokeChecked;
 	try {
 		await codemode.package_invoke_checked({
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/worker/src/package-runtime/module-graph.workers.test.ts` around
lines 573 - 582, Add a short inline comment above the try/catch that calls
codemode.package_invoke_checked explaining that the call is expected to reject
(so the test asserts failure) due to the PR's behavioral change preventing
direct invocation; reference the function name codemode.package_invoke_checked
and the test variable directCodemodeInvokeChecked in the comment and briefly
state the reason (e.g., direct package invoke is disallowed in this worker test)
so future maintainers understand why the test expects an error.

660-662: ⚡ Quick win

Consider making the failure expectation more explicit.

The assertion correctly verifies that the error message contains 'package_invoke_checked', but you could make it clearer that the call is expected to fail by also asserting the value is not 'resolved'.

🔍 More explicit assertion
 	directCodemodeInvokeChecked: expect.stringContaining(
 		'package_invoke_checked',
 	),
+	// Alternatively, be more explicit:
+	// expect(result.result.directCodemodeInvokeChecked).not.toBe('resolved')
+	// expect(result.result.directCodemodeInvokeChecked).toContain('package_invoke_checked')
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/worker/src/package-runtime/module-graph.workers.test.ts` around
lines 660 - 662, The test currently asserts that directCodemodeInvokeChecked
contains 'package_invoke_checked' but doesn't clearly express that the call
failed; update the assertion for directCodemodeInvokeChecked to also assert the
value is not 'resolved' (e.g., add an expectation using
expect.not.toBe('resolved') or equivalent) so the test explicitly verifies the
call did not succeed while still checking for the 'package_invoke_checked' text.

691-700: ⚡ Quick win

Consider adding a comment explaining the expected rejection.

Same as the previous test: this code verifies that direct codemode.package_invoke_checked calls are rejected. A brief comment would clarify the intent for future maintainers.

📝 Suggested comment
+	// Direct codemode.package_invoke_checked calls should reject; packages.invokeChecked is the public API
 	let directCodemodeInvokeChecked;
 	try {
 		await codemode.package_invoke_checked({
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/worker/src/package-runtime/module-graph.workers.test.ts` around
lines 691 - 700, Add a short inline comment above the try/catch that explains
the test expects codemode.package_invoke_checked to reject when invoked
directly: reference the local variable directCodemodeInvokeChecked and the call
codemode.package_invoke_checked({ kodyId: 'target-package', exportName: './run'
}) so future maintainers understand that the try block should not resolve and
the catch path captures the rejection message.

770-772: ⚡ Quick win

Consider making the failure expectation more explicit.

Same suggestion as the previous test: the assertion is correct but could be clearer about expecting failure by also checking that the value is not 'resolved'.

🔍 More explicit assertion
 	directCodemodeInvokeChecked: expect.stringContaining(
 		'package_invoke_checked',
 	),
+	// Alternatively, be more explicit:
+	// expect(result.result.directCodemodeInvokeChecked).not.toBe('resolved')
+	// expect(result.result.directCodemodeInvokeChecked).toContain('package_invoke_checked')
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/worker/src/package-runtime/module-graph.workers.test.ts` around
lines 770 - 772, The assertion for directCodemodeInvokeChecked currently only
checks for stringContaining('package_invoke_checked'); add an explicit negative
check that the value is not the success marker 'resolved' to make the failure
expectation clearer—locate the test using the directCodemodeInvokeChecked
matcher in module-graph.workers.test.ts and add a companion assertion (e.g.,
expect(...).not.toBe('resolved') or
expect(...).not.stringContaining('resolved')) targeting the same value so the
test both expects the failure token and asserts it's not the successful
'resolved' token.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/worker/src/mcp/run-codemode-registry.node.test.ts`:
- Around line 1557-1573: The test's execute(...) callback indexes providers[1]
without asserting providers length first; add an explicit assertion on providers
(e.g., expect(providers).toHaveLength(expected) or
expect(providers.length).toBeGreaterThan(1)) before assigning providerFns and
packageBridgeFns so a missing bridge provider fails with a clear contract-level
message; update the block around execute(wrapped, providers) to assert
providers' cardinality prior to using providers[0] and providers[1] (references:
execute, providers, providerFns, packageBridgeFns).

In `@packages/worker/src/package-runtime/module-graph.workers.test.ts`:
- Around line 573-582: Add a short inline comment above the try/catch that calls
codemode.package_invoke_checked explaining that the call is expected to reject
(so the test asserts failure) due to the PR's behavioral change preventing
direct invocation; reference the function name codemode.package_invoke_checked
and the test variable directCodemodeInvokeChecked in the comment and briefly
state the reason (e.g., direct package invoke is disallowed in this worker test)
so future maintainers understand why the test expects an error.
- Around line 660-662: The test currently asserts that
directCodemodeInvokeChecked contains 'package_invoke_checked' but doesn't
clearly express that the call failed; update the assertion for
directCodemodeInvokeChecked to also assert the value is not 'resolved' (e.g.,
add an expectation using expect.not.toBe('resolved') or equivalent) so the test
explicitly verifies the call did not succeed while still checking for the
'package_invoke_checked' text.
- Around line 691-700: Add a short inline comment above the try/catch that
explains the test expects codemode.package_invoke_checked to reject when invoked
directly: reference the local variable directCodemodeInvokeChecked and the call
codemode.package_invoke_checked({ kodyId: 'target-package', exportName: './run'
}) so future maintainers understand that the try block should not resolve and
the catch path captures the rejection message.
- Around line 770-772: The assertion for directCodemodeInvokeChecked currently
only checks for stringContaining('package_invoke_checked'); add an explicit
negative check that the value is not the success marker 'resolved' to make the
failure expectation clearer—locate the test using the
directCodemodeInvokeChecked matcher in module-graph.workers.test.ts and add a
companion assertion (e.g., expect(...).not.toBe('resolved') or
expect(...).not.stringContaining('resolved')) targeting the same value so the
test both expects the failure token and asserts it's not the successful
'resolved' token.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2d594418-a268-4c22-b09d-784ecab30f90

📥 Commits

Reviewing files that changed from the base of the PR and between de5a8ae and 18e90b1.

📒 Files selected for processing (3)
  • packages/worker/src/mcp/run-codemode-registry.node.test.ts
  • packages/worker/src/mcp/run-codemode-registry.ts
  • packages/worker/src/package-runtime/module-graph.workers.test.ts

Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>
@kentcdodds
kentcdodds merged commit 8306448 into main May 14, 2026
5 checks passed
@kody-bot
kody-bot deleted the de-emphasize-codemode-package-invocation branch July 21, 2026 19:01
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.

De-emphasize codemode package invocation bridge

2 participants