Repository navigation
Description
On Windows the updater's NSIS installer can take many minutes to unpack resources\app.asar.unpacked\node_modules. On this machine it ran 09:09:07 -> ~09:20 (~11 minutes) for 14,667 files. Throughout that window the app has already quit for the update, no progress UI is shown, and T3 Code (Nightly).exe plus the taskbar/Start Menu shortcuts remain launchable.
Launching mid-extraction produces an uncaught main-process exception:
A JavaScript error occurred in the main process
Uncaught Exception:
Error [ERR_MODULE_NOT_FOUND]: Cannot find module
'C:\Users\<redacted>\AppData\Local\Programs\t3code\resources\app.asar\node_modu...\Context'
imported from
C:\Users\<redacted>\AppData\Local\Programs\t3code\resources\app.asar\no...\NodeHttpClient.js
at finalizeResolution (node:internal/modules/esm/resolve:275:11)
at moduleResolve (node:internal/modules/esm/resolve:873:10)
at defaultResolve (node:internal/modules/esm/resolve:1000:11)
app.asar is already in place from the prior version, so the exe starts, but the unpacked modules it imports have not been written yet. Once the installer finishes it relaunches the app itself with --updated and everything works normally.
Why this is worth guarding
This is byte-identical to the signature in #4154, which is a genuine packaging regression where effect is actually missing from the asar. Users who hit the race will file duplicates of it. The two are easy to tell apart after the fact, but not at the moment the dialog appears:
- Race (this issue):
resources\app.asar.unpacked\node_modules\effect\dist\Context.jsis present once the installer finishes. - Nightly 0.0.29-nightly.20260719.849 won't launch on Windows: effect missing from app.asar.unpacked (ERR_MODULE_NOT_FOUND Context) #4154: that file is absent even on a fully completed install.
I verified the former on this machine. After the install completed, effect\dist\Context.js, effect\package.json, @effect\platform-node, undici, and mime were all present, and the app launched fine.
Steps to reproduce
- On Windows, be on a machine where extraction is slow (spinning disk, throttled CPU, or heavy concurrent load).
- Trigger an update from within the app so it quits and hands off to the NSIS installer.
- While the
T3-Code-<version>-x64installer process is still running, click the T3 Code taskbar or Start Menu shortcut. - Observe the uncaught exception dialog.
Whether an install is still in flight is visible as a running process named T3-Code-<version>-x64 (distinct from T3 Code (Nightly)).
Expected behavior
Launching during an update either does nothing, or shows something like "Update in progress, please wait" rather than a raw stack trace.
Suggested fixes
Roughly in order of cheapness:
- Have the installer remove or retarget the shortcuts while extraction is in progress and restore them at the end.
- Write a sentinel file at the start of extraction and delete it at the end; the main process checks for it on startup and shows a friendly "update in progress" message instead of throwing.
- Show installer progress at all, so the multi-minute silent window is at least visible.
Any one of these also cuts down the false-positive duplicates of #4154.
Environment
- OS: Windows 11 Pro (win32 10.0.26200), x64
- App: T3 Code (Nightly)
0.0.32-nightly.20260806.1015 - Install path:
%LocalAppData%\Programs\t3code - Updater path:
%LocalAppData%\t3code-updater\pending\ - Extraction measured at roughly 96 files/sec for 14,667 files
Activity
JeremieLeblanc commentedon Aug 12, 2026
Adding a data point: in my case the interrupted extraction wasn't transient — it left a
permanently truncated install that crash-looped for over two weeks, and the updater could
never recover on its own.
Environment: Windows 11 Pro (build 26200), nightly channel.
Timeline (reconstructed from file timestamps):
0.0.29-nightly.20260727.918began extracting into%LOCALAPPDATA%\Programs\t3-code-desktopat 8:52:56 AM and stopped ~15 seconds later.resources\app.asar.unpacked\node_moduleswas left with exactly 82 packages, endingalphabetically at
lodash—pure-randand everything after it missing.ERR_MODULE_NOT_FOUND: Cannot find module '...\pure-rand\...\congruential32' imported from ...\fast-check.js(same as OP).0.0.34-nightly.20260811.1069to%LOCALAPPDATA%\t3code-updater\pending(sha512 verified correct), but it was neverapplied — the main process crashes before the auto-install-on-quit hook can run. So a
broken install can't self-heal even with a valid update sitting on disk; the only exit
is a manual reinstall.
Related wrinkle: the install directory was renamed between 0.0.29
(
Programs\t3-code-desktop) and 0.0.34 (Programs\t3code). The installer rewrote theStart Menu and Desktop shortcuts but not the pinned taskbar shortcut, which kept
pointing at the orphaned broken copy — so even after a successful reinstall, launching
from the taskbar reproduces the crash and looks like the update failed again. The old
directory (1.3 GB) is also left behind with no uninstall entry.
Suggestions:
— if it's missing and a hash-valid installer exists in
pending, re-run it instead ofcrash-looping.
juliusmarminge commentedon Oct 27, 2026
Thanks for the detailed timing and file counts. This was fixed on main by c9063f0 (https://git.cafe/pingdotgg/t3code/pulls/6169, merged 2026-08-14), which shipped after 0.0.32-nightly.20260806.1015. It moves the bundled server and its JS dependencies into
resources/server.asarand keeps only native binaries loose. The release build now fails any Windows package that has more than 80 loose files.What I checked:
app-64.7zfrom both NSIS installers with 7-Zip.0.0.32-nightly.20260806.1015: 14,690 files. 14,667 of them are underapp.asar.unpacked, the number you measured, and 9,067 of those are JS, includingeffect/dist/Context.js.0.1.3-nightly.20261026.3740: 53 files. 8 are underapp.asar.unpacked, and none of them are JS..asararchives, without their.unpackedsiblings, and launched eachapp.asarwith Electron 44.9.3 on Linux/Xvfb.Uncaught Exception: Error: Cannot find module '@effect/platform-node/NodeHttpClient'.effectinlined, so it no longer loads JS from.unpacked.The same change covers the truncated-
node_modulescrash loop described in the comment above: there are no longer thousands of loose JS files to leave half-written. Closing as fixed. If a current nightly still shows this dialog during an update, please open a new issue with the version and the full error text.