fix(desktop): resolve plugin SDK namespaces at call time

[LisandroNahuelH]

What does this PR do?

Fixes every runtime (disk-door) desktop plugin failing to load after the recent bundle change:

[plugins] runtime load failed (<id>) TypeError: Cannot convert undefined or null to object (…/app.asar.unpacked/dist/assets/sdk-*.js:5)

Root cause: inside the built sdk chunk, src/sdk/runtime.ts's module section can evaluate BEFORE the section that assigns the ./index namespace binding it reads — the module cycle (sdk/index → contrib/* → contrib/runtime-loader → sdk/runtime) is preserved as concatenated sections, and the namespace read is a hoisted var that is still undefined at that point. The module-level GLOBALS object then froze those undefined values, so the first shim built on plugin load died on Object.keys(undefined) — for every plugin, including a zero-import probe plugin (the error points at the app's own chunk, not plugin code).

The fix resolves the namespaces at CALL time (sdkGlobals() read by installPluginSdk() and the shim builder) instead of capturing them at module-eval time. Both call sites only run after boot, when every binding is assigned. Single file, no API change.

Transparency note: this is the same lazy-read direction as #107303 and is submitted at the author's request as a minimal corroborating variant (maintainers: prefer whichever candidate you pick — happy to close this one in favor of the canonical fix). Related issue: #107288.

Related Issue

Related: #107288 — same regression and same diagnosis (this intentionally does not claim uniqueness; see note above).

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• apps/desktop/src/sdk/runtime.ts: replace the module-level GLOBALS constant with a sdkGlobals() accessor called by installPluginSdk() and shimUrl(), so the SDK/React namespaces are resolved at call time (post-boot) rather than captured during chunk evaluation.

How to Test

Repro on base (any packaged build of current main):

1. Drop any runtime plugin at $HERMES_HOME/desktop-plugins/<id>/plugin.js — an empty probe (export default { id: 'probe', register() {} }) is enough.
2. It fails with the TypeError above; logs/desktop.log shows [plugins] runtime load failed (…) pointing at sdk-*.js:5.

Proof the fix works (packaged Windows build, release/win-unpacked, Electron 40.10.2, desktop 0.17.2 / core v0.21.1):

1. Chunk-level probe (instrumented the built shim builder to log the namespace object per shim key, then invoked the import-map builder in real Electron): base build logs __HERMES_PLUGIN_SDK__ → undefined and throws on the first Object.keys; with this patch all four namespaces log object and the import map builds.
2. App level (patched build swapped into release/win-unpacked): all runtime plugins load — no runtime load failed lines after boot — and the affected statusbar chips render.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate — it IS related to fix(desktop): resolve plugin SDK namespaces lazily so disk plugins load in production builds #107303/fix(desktop): lazy-load runtime-loader to break the sdk/index cycle #107301/fix(desktop): tolerate null SDK namespaces when preparing runtime plugin shims #107309 (see transparency note; submitted knowingly, at the reporter's request, cross-linked for triage)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — N/A for this change: it is a desktop TypeScript-only change; the Python suite is untouched (CI runs the full matrix)
• I've added tests for my changes — not in this PR: the failure requires the bundled chunk's section order (module cycle), which a vitest/ESM graph cannot reproduce; a behaviour-level test companion for this lazy-read direction exists in test(desktop): cover SDK namespace cycles and production plugin loading #107405
• I've tested on my platform: Windows 11 (packaged release/win-unpacked build, Electron 40.10.2)

Documentation & Housekeeping

• I've updated relevant documentation — N/A (code comment in runtime.ts documents the cycle and the lazy-read requirement)
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) — the fix is renderer-side and platform-agnostic; verified on Windows, the same lazy-read approach was independently verified on Linux in fix(desktop): resolve plugin SDK namespaces lazily so disk plugins load in production builds #107303's thread
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

Before (base build, instrumented probe):

Cg key= __HERMES_PLUGIN_SDK__ typeof= undefined
TypeError: Cannot convert undefined or null to object
    at Object.keys (<anonymous>)
    at Cg (…/sdk-*.js:5:26820) …

After (same probe, patched build):

Cg key= __HERMES_PLUGIN_SDK__ typeof= object
Cg key= __HERMES_REACT_JSX_DEV__ typeof= object
Cg key= __HERMES_REACT_JSX__ typeof= object
Cg key= __HERMES_REACT__ typeof= object
→ import map builds, plugins load, no `runtime load failed` lines after restart

[alt-glitch]

This was generated by AI during triage.

Duplicate of #107303 (earliest open fix, same lazy-namespace-resolution approach in apps/desktop/src/sdk/runtime.ts), per the author's own transparency note. Same cluster: #107603, #107518, #107309, #107338, all for #107288. Maintainer to pick one.

[kshitijk4poor]

Closing as a duplicate of #107303 (@g3org3yo, merged as 6c3d4a4 on 2026-09-10), which lands the same fix — apps/desktop/src/sdk/runtime.ts resolves the plugin SDK namespaces at call time via pluginNamespaces() instead of a module-init GLOBALS snapshot. Current main already carries it, and this branch now conflicts on that block.

Thanks for the independent diagnosis — the issue was real and the approach matched what merged. Credit for the fix goes to the earliest submitter per repo policy; if a follow-up gap surfaces in production builds, please open a fresh PR against current main.