[Bug]: last 24 hours of Nightly's failing to start on Windows 10

[gdfeltti]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

I hit the update button, and after the install T3 wouldn't start, I checked my Task manager and saw three T3 processes, but it never opened. did a fresh reboot, and the application would still not open.
I then installed the previous nightly version and I again saw 3 processes this time after the install window closed.
I then rebooted and still couldn't open it.
I tried one more version after an uninstall (I forget which one it was though). same issue.

I then jumped back 2 days of nightly builds and the window opened right up after the install.

FAILED TO START ON WINDOWS 10

• T3 Code Nightly 0.0.29-nightly.20260708.758 (0c66565)
• T3 Code Nightly 0.0.29-nightly.20260708.754 (03ac1f0)

PREVIOUS VERSION REVERTED TOO SUCCESSFULLY

• T3 Code Nightly 0.0.29-nightly.20260706.739 (32e7844)

Expected behavior

T3 code window to render after an update.

Actual behavior

T3 code window to open/render after an update operation is performed.

Impact

Blocks work completely

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[Noisemaker111]

Did some digging — highly probable cause found. This looks like a second fallout from the pnpm 11 bump (#3772), distinct from what #3790 fixed.

What's broken: The Windows nightlies since the pnpm 11 bump ship without @yuuang/ffi-rs-win32-x64-msvc (and ~44 other optional-dep packages) in app.asar.unpacked/node_modules. I extracted and diffed the .751 (good) and .758 (broken) installers to confirm: ffi-rs and @ff-labs/fff-node are present, but the entire @yuuang/ scope is missing. The server child process crashes on its first import (@ff-labs/fff-node → ffi-rs → require('@yuuang/ffi-rs-win32-x64-msvc')), restarts in a silent loop, and since window creation waits on backend readiness, no window ever appears — the 3 processes are just Electron's main/GPU/network. scripts/build-desktop-artifact.ts even documents this exact crash-loop in a comment.

Why: electron-builder mis-detects the package manager for the staged app dir as npm (its workspace-root re-detection silently falls back to env detection, and the build runs via vp exec so no pnpm user-agent is set — visible in the Build Windows x64 log of the .758 release run: searching for node modules pm=npm). The npm collector run against a pnpm layout drops optional-dependency subtrees on Windows. It worked before by accident: in the .751 build the npm collector returned depCount=0 and electron-builder 26.8.1 fell back to filesystem traversal (depCount=294, everything shipped). In .758, 26.15.6's npm collector "succeeds" with depCount=178, so the fallback never fires. macOS survives because npm's output happens to be sufficient there — which is why the #3790 verification passed.

Likely fix: set npm_config_user_agent (e.g. pnpm/11.10.0, derived from the root packageManager field) in the electron-builder spawn env in scripts/build-desktop-artifact.ts, so its pnpm collector handles the stage (traversal remains as fallback). Verified the mechanism locally on Windows 10 with electron-builder 26.15.6 against a pnpm-11-installed project with platform optional deps: without the env var, pm=npm; with it, pm=pnpm and both host and supportedArchitectures foreign platform binaries land in the artifact. Acceptance check for the next nightly: Windows job log shows pm=pnpm with depCount ≈ 294 (was 178), and app.asar.unpacked/node_modules/@yuuang/ffi-rs-win32-x64-msvc exists.

Workaround until then: roll back to v0.0.29-nightly.20260707.751. Affected machines should show the Cannot find module '@yuuang/ffi-rs-win32-x64-msvc' crash loop in %USERPROFILE%\.t3\userdata\logs\server-child.log.

_{— with Fable 5}

[gdfeltti]

a snippet from server-child.log:
{"message":"backend child process output","level":"ERROR","timestamp":"2026-07-08T15:45:20.135Z","annotations":{"component":"desktop-backend-child","runId":"e4cad3559d33","instanceId":"primary","stream":"stderr","text":"node:internal/modules/cjs/loader:1483\r\n const err = new Error(message);\r\n ^\r\n\r\nError: Cannot find module '@yuuang/ffi-rs-win32-x64-msvc'\r\nRequire stack:\r\n- C:\\Users\\<username>\\AppData\\Local\\Programs\\t3code\\resources\\app.asar\\node_modules\\ffi-rs\\index.js\r\n at Module._resolveFilename (node:internal/modules/cjs/loader:1483:15)\r\n at wrapResolveFilename (node:internal/modules/cjs/loader:1056:27)\r\n at defaultResolveImplForCJSLoading (node:internal/modules/cjs/loader:1080:10)\r\n at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1101:12)\r\n at Module._load (node:internal/modules/cjs/loader:1269:25)\r\n at c._load (node:electron/js2c/node_init:2:18060)\r\n at wrapModuleLoad (node:internal/modules/cjs/loader:262:19)\r\n at Module.require (node:internal/modules/cjs/loader:1583:12)\r\n at require (node:internal/modules/helpers:153:16)\r\n at Object.<anonymous> (C:\\Users\\<username>\\AppData\\Local\\Programs\\t3code\\resources\\app.asar\\node_modules\\ffi-rs\\index.js:66:29) {\r\n code: 'MODULE_NOT_FOUND',\r\n requireStack: [\r\n 'C:\\\\Users\\\\<username>\\\\AppData\\\\Local\\\\Programs\\\\t3code\\\\resources\\\\app.asar\\\\node_modules\\\\ffi-rs\\\\index.js'\r\n ]\r\n}\r\n\r\nNode.js v24.15.0\r\n"},"spans":{},"fiberId":"#backend-child"} {"message":"backend child process session end","level":"INFO","timestamp":"2026-07-08T15:45:20.149Z","annotations":{"component":"desktop-backend-child","runId":"e4cad3559d33","instanceId":"primary","phase":"END","details":"pid=40180 code=1"},"spans":{},"fiberId":"#backend-child"}
That looks about right. I see:
Cannot find module '@yuuang/ffi-rs-win32-x64-msvc'

[skjiisa]

Seems to be platform agnostic and a duplicate of #3804