PR #69925: perf(plugins): prefer native jiti for bundled plugin dist modules

• Repository: openclaw/openclaw
• Author: aauren
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/69925

Description (problem / solution / changelog)

Summary

cc @gumadeiras

Full disclosure: I'm not a Node developer (I mainly work in Go / infra), and AI assistance was used to help me navigate this codebase, identify the root cause, and validate the change. I understand what the code does and verified it myself though.

• Problem: resolvePluginLoaderJitiTryNative in sdk-alias.ts unconditionally returns false for bundled plugin dist paths, forcing every getCachedPluginJitiLoader caller through jiti's slow transform pipeline — even for pre-built .js/.mjs/.cjs files that Node can load natively.
• Why it matters: Users are reporting 17-42s openclaw status times. This is one of the remaining contributors after #69786 landed the nodeRequire fast-path fix for loadBundledEntryModuleSync.
• What changed: One line — the early-return false now delegates to shouldPreferNativeJiti(modulePath), which already correctly gates on platform (!win32, !bun) and file extension (.js/.mjs/.cjs/.json). Updated the corresponding test to match.
• What did NOT change (scope boundary): No new dependencies, no plugin behavior, no Windows/Bun behavior (they still get false via shouldPreferNativeJiti), no changes outside src/plugins/.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related #68282
• Related #69462
• Related #69758
• Supersedes #68348 and #68324 (those fix individual call sites; this fixes the root cause)
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: isBundledPluginDistModulePath(modulePath) guard in resolvePluginLoaderJitiTryNative hard-returns false, bypassing the shouldPreferNativeJiti() check that already knows how to make the right platform-aware decision.
• Missing detection / guardrail: The existing test asserted false as the expected value, so it was "working as designed" — just designed conservatively.
• Contributing context (if known): The return false may have originally been a safety net before shouldPreferNativeJiti() had proper platform gating. Now that it handles win32 and bun correctly, the hard false is just unnecessary overhead.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/sdk-alias.test.ts
• Scenario the test should lock in: Bundled plugin dist .js modules return shouldPreferNativeJiti() (true on Linux/macOS, false on Windows/Bun); .ts files still return false.
• Why this is the smallest reliable guardrail: Tests the decision function directly without needing to spin up the full loader.
• Existing test that already covers this (if any): Updated the existing "keeps bundled plugin dist modules on the aliased Jiti path" test — renamed it to reflect the new behavior.
• If no new test is added, why not: Existing test was updated, not removed.

User-visible / Behavior Changes

None. CLI commands that load bundled plugins (status, health, etc.) should be faster on Linux/macOS. Output is identical.

Diagram (if applicable)

Before:
[bundled dist/extensions/*.js] -> resolvePluginLoaderJitiTryNative -> return false -> jiti parse (slow)

After:
[bundled dist/extensions/*.js] -> resolvePluginLoaderJitiTryNative -> shouldPreferNativeJiti() -> true on Linux/macOS -> jiti native delegation (fast)
                                                                                                -> false on Win32/Bun -> jiti parse (unchanged)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Ubuntu Linux (also affects macOS)
• Runtime/container: Node v24.14.1
• Model/provider: N/A
• Integration/channel (if any): All bundled channels — most visible with Discord/Telegram
• Relevant config (redacted): Default config with at least one channel plugin configured

Steps

1. openclaw status --json on a fresh process (Linux or macOS)
2. Observe startup time dominated by jiti transform for bundled plugin dist files

Expected

• Bundled .js dist files load via native delegation, not jiti forced-parse

Actual

• Before this fix: resolvePluginLoaderJitiTryNative returns false for all bundled dist paths, forcing jiti parse on every caller of getCachedPluginJitiLoader

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Profiling data from the detailed investigation in #68282 and #69462 shows jiti.normalizeAliases as the dominant hot frame in startup. The shouldPreferNativeJiti microbenchmark in the original analysis shows tryNative: false at 3347ms vs native at 2560ms per file — compounded across all bundled plugin dist modules this adds up to the ~1.5-4s savings this change provides (on top of the ~12.5s already saved by #69786).

Full validation suite run:

Human Verification (required)

• Verified scenarios: Full validation suite (pnpm build && pnpm check && pnpm test), contract tests, boundary checks, and extension memory profiler all pass. I have also been running openclaw with this patch for the last couple of days on a Linux host and it has produced a noticeable speed-up.
• Edge cases checked: Windows behavior preserved (returns false via shouldPreferNativeJiti), .ts files still routed through jiti transform, Bun excluded via supportsNativeJitiRuntime().
• What you did not verify: I don't have access to Windows or Bun to verify those paths at runtime (relied on existing test coverage and code inspection).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

N/A — first submission.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: If any bundled dist/extensions/**/*.js module relies on jiti alias resolution that Node's native loader can't handle, it would fail on first attempt.
  • Mitigation: jiti's built-in fallback handles this — tryNative: true means "try native first, fall back to transform." The existing try/catch in loadBundledEntryModuleSync also provides a second safety net. This is the same pattern used by every other non-bundled dist path in the loader already.

[AI-assisted] — AI was used to navigate the codebase, identify the root cause, prepare the change, and validate it. I reviewed and understand all changes.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/sdk-alias.test.ts (modified, +6/-2)
• src/plugins/sdk-alias.ts (modified, +1/-1)