loader: internal resolveSync mis-tagged v2 on Node 24.11 — client boot graph composes empty (fix ready)

[wuxuzhilu]

"# Bug: loader mis-tags the internal resolveSync on Node 24.11 \u2014 client boot graph composes empty (fix ready)\n\n## Environment\n\n- Node 24.11.1 (win32-x64)\n- @cordisjs/plugin-loader 1.0.0-rc.5 (vendored at 56b3d4f7 in deepseek-harness; current main has the same code)\n\n## Symptom\n\nWith dsh web on Node 24.11.1, the web UI fails with:\n\n\nclient-modules: HTML did not preload @deepseek-ai/dsh-client-modules/client.js\n\n\nThe server composes an empty client boot graph (__DSH_BOOT__ has zero entries and zero batches) because every client package's manifest resolution fails and is silently dropped.\n\n## Root cause\n\nModuleLoader.fromInternal() in packages/loader/src/internal.ts tags the Node internal ESM loader by major version \u2014 Node \u2265 24 is tagged v2, whose resolveSync(parentURL, request) takes a request object. On Node 24.11.1 the private resolveSync still has the v1 argument order (specifier, parentURL, importAttributes) \u2014 the order earlier Node 24 releases had replaced \u2014 so the v2-shaped call passes the request object into the parent-URL position and Node's sync-hook resolution throws TypeError: e.indexOf is not a function.\n\nConsumers (hmr, client-modules) classify any such resolution failure as "this name is not a client row" and skip it silently. The private signature has churned within the Node 24 line, so a major-version check cannot identify it.\n\nDependency-free repro:\n\nsh\nnode --expose-internals -e \"\nconst raw = require('internal/modules/esm/loader').getOrInitializeCascadedLoader();\ntry { raw.resolveSync('file:///', { specifier: 'node:path', attributes: {} }); console.log('v2-order OK'); }\ncatch (e) { console.log('v2-order throws:', e.message); }\ntry { console.log('v1-order OK:', raw.resolveSync('node:path', 'file:///', {}).url); }\ncatch (e) { console.log('v1-order throws:', e.message); }\n\"\n\n\nOn 24.11.1 the v2 order throws ERR_INVALID_ARG_TYPE (under a host that registers module.registerHooks, it surfaces as TypeError: e.indexOf is not a function); the v1 order resolves node:path.\n\n## Fix\n\nDetect the parameter order behaviorally instead of trusting the major version: probe one builtin resolution with the v1 order first (a v1 loader short-circuits any first argument that already parses as a URL, which would mask a v2 probe), then the v2 order, keep the version that returns a URL, and throw when neither matches.\n\nA complete patch is on my fork branch \u2014 wuxuzhilu:fix/loader-probe-resolve-sync-version (vendor probe + vendor/README.md local-modification ledger entry + bilingual agent note). I tried to open a PR but this repository has pull requests disabled, so I am sharing the change here; happy to open a PR if that becomes possible, or feel free to take the change.\n\n## Verification\n\n- Focused suites (app-boot, webserver): 137 tests pass.\n- Full pnpm run build passes.\n- Live: the dsh web boot graph went from 0 entries to 46; the bootstrap batch serves 200 with the __ModuleLoader__.load registration the queue script waits for.\n"

[liyangbing]

这个修复对应的是 Host resolver 边界

你给出的证据链很完整：Node 24.11.1 下 resolveSync 的实际参数顺序与按大版本选择的 v2 调用不一致，异常又被 client-modules/hmr 当作“不是 client row”静默跳过，最终才表现为 __DSH_BOOT__ 为空和 HTML preload 错误。因此不要先清浏览器缓存或放宽 preload 断言；那会掩盖 Host 侧的空图。

建议把行为探测和启动验证固定成同一份证据：记录 Node 版本、首次 resolver 异常、__DSH_BOOT__ 的 entries/batches、HTML 中的 parser-blocking bootstrap URL，以及从同一 Host generation 获取的 /plugins 状态码、Content-Type、长度和 hash。对比 Node 22 与 Node 24.11.1 时保持相同 profile、源码 revision 和构建产物。

我整理了一份独立社区手册，专门覆盖这个错误的 Host/Node/HTML 边界、零依赖启动诊断和安全恢复顺序：Fix HTML did not preload client-modules。它不是 DeepSeek 官方文档；请以当前上游 revision 和你们的实测结果为准。