fix(desktop): keep node:crypto out of the renderer's protocol barrel import graph - #4720
Closed
bytelazy wants to merge 1 commit into
Closed
fix(desktop): keep node:crypto out of the renderer's protocol barrel import graph#4720bytelazy wants to merge 1 commit into
bytelazy wants to merge 1 commit into
Conversation
…import graph The renderer startup graph pulls a value import from @maka/runtime-host/protocol (MESSAGE_QUEUE_MAX_ENTRIES in session-workspace-actions.ts). The barrel re-exports client-capability.js, which imported node:crypto for clientCapabilityEntityId. Vite dev does no tree-shaking, so evaluating the barrel evaluates client-capability.js in the browser, and the top-level node:crypto destructure throws — the renderer stays on the preload skeleton forever with no terminal error. Move clientCapabilityEntityId into its own Node-only module (packages/runtime-host/src/capability-entity-id.ts) with the node:crypto import, and re-export it as @maka/runtime-host/capability-entity-id (the same shape as profile-kind). Point the three call sites (two desktop main, one cli) at it. The protocol barrel and every module it export-* now has no node: builtin, so the renderer can import browser-safe values from it without evaluating node:crypto. Add a unit test for clientCapabilityEntityId, which had none before, so the moved behavior is pinned. Fixes apache#4706 Generated-by: Claude (Claude Code)
Author
|
Closing — #4705 landed the same fix (merged 2026-09-04 02:38 UTC) while this PR was still in the review queue. Same root cause, same approach (move clientCapabilityEntityId into a Node-only Runtime Host export), and #4705 is more complete: it also adds a protocol-compatible-changes entry and a vite-workspace-packages regression test that mine lacks. No reason to keep this open. Sorry for the duplicate — I should have checked recently-merged PRs, not just open ones, before opening this. |
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
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.
Summary
The Desktop renderer stays on the
index.htmlpreload skeleton forever when launched withvite dev. The renderer startup graph imports a value (MESSAGE_QUEUE_MAX_ENTRIES) from@maka/runtime-host/protocol, whose barrelexport *re-exportsclient-capability.js. That module importednode:cryptoforclientCapabilityEntityId. Vite dev does no tree-shaking, so evaluating the barrel evaluatesclient-capability.jsin the browser, where the top-levelnode:cryptodestructure throws and kills the renderer import graph before React mounts — with no terminal error.The fix moves
clientCapabilityEntityId(and itsnode:cryptoimport) out ofprotocol/client-capability.tsinto a Node-only modulepackages/runtime-host/src/capability-entity-id.ts, re-exported as@maka/runtime-host/capability-entity-id(the same standalone-subpath shape asprofile-kind). The three call sites (two Desktop main-process, one CLI) import it from there. The protocol barrel and every module it re-exports are now free ofnode:builtins, so the renderer can keep importing browser-safe values without evaluatingnode:crypto.clientCapabilityEntityIdhad no unit test before; one is added so the moved behavior is pinned.Verification of the root cause against the current tree:
packages/runtime-host/src/protocol/client-capability.ts:20importednode:crypto, the only Node builtin in the barrel'sexport *closure.export * from './*.js'target inpackages/runtime-host/src/protocol/index.tsconfirms no othernode:builtin remains.MESSAGE_QUEUE_MAX_ENTRIES(value) from the barrel insession-workspace-actions.ts:38, which is what triggers module evaluation.Fixes #4706
Verification
clientCapabilityEntityId(5 cases): wire-safe passthrough, space/punctuation normalization, over-length truncation, digest distinction, explicit max length — all pass withnode --test --experimental-strip-types(Node v24.20.0).clientCapabilityEntityIdreferences now point only at the new module and the three call sites; no call site still imports it from@maka/runtime-host/protocol.client-capability.tshas no remainingnode:crypto/createHashreference.tsconfig.json(include: ['src'],rootDir: src,outDir: dist) compilessrc/capability-entity-id.tstodist/capability-entity-id.js, matching the addedexports["./capability-entity-id"]— same pattern as the existingprofile-kindsubpath.Not run: the full Desktop dev launch (
npm run dev) and the runtime-hosttest:dist/typecheck, because a full workspacenpm cidoes not complete from this network. The change is a pure relocation with no logic change and a pinned unit test; a maintainer with the workspace installed can confirmnpm run devrenders past the skeleton, andnpm --workspace @maka/runtime-host run typecheck.AI use
Tool(s) and scope: Claude Code — traced the import chain to the
node:cryptosource, relocatedclientCapabilityEntityId, updated the call sites and exports, and wrote the unit test. The commit carries aGenerated-by: Claude (Claude Code)trailer.Checklist
(The runtime-host typecheck/test suites are not runnable from this environment as noted under Verification; the new unit test passes locally via type-stripping.)
Does this PR entail a change in behavior?
vite dev, which it could not before.